1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* index.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* code to create and destroy POSTGRES index relations
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/catalog/index.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* INTERFACE ROUTINES
|
1997-09-07 07:04:48 +02:00
|
|
|
* index_create() - Create a cataloged index relation
|
1999-12-10 04:56:14 +01:00
|
|
|
* index_drop() - Removes index relation from catalogs
|
2000-07-15 00:18:02 +02:00
|
|
|
* BuildIndexInfo() - Prepare to insert index tuples
|
|
|
|
* FormIndexDatum() - Construct datum vector for one index tuple
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
1998-01-13 05:05:12 +01:00
|
|
|
#include "postgres.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-12-09 21:32:44 +01:00
|
|
|
#include <unistd.h>
|
1999-07-16 07:00:38 +02:00
|
|
|
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
#include "access/amapi.h"
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
#include "access/multixact.h"
|
2008-06-19 02:46:06 +02:00
|
|
|
#include "access/relscan.h"
|
2008-05-12 02:00:54 +02:00
|
|
|
#include "access/sysattr.h"
|
2006-07-13 18:49:20 +02:00
|
|
|
#include "access/transam.h"
|
2011-10-14 23:23:01 +02:00
|
|
|
#include "access/visibilitymap.h"
|
2006-07-13 18:49:20 +02:00
|
|
|
#include "access/xact.h"
|
1998-01-13 05:05:12 +01:00
|
|
|
#include "bootstrap/bootstrap.h"
|
2013-12-19 22:10:01 +01:00
|
|
|
#include "catalog/binary_upgrade.h"
|
2000-11-08 23:10:03 +01:00
|
|
|
#include "catalog/catalog.h"
|
2002-07-12 20:43:19 +02:00
|
|
|
#include "catalog/dependency.h"
|
1998-01-13 05:05:12 +01:00
|
|
|
#include "catalog/heap.h"
|
|
|
|
#include "catalog/index.h"
|
2012-10-23 23:07:26 +02:00
|
|
|
#include "catalog/objectaccess.h"
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
#include "catalog/pg_am.h"
|
2011-02-12 14:54:13 +01:00
|
|
|
#include "catalog/pg_collation.h"
|
2002-07-12 20:43:19 +02:00
|
|
|
#include "catalog/pg_constraint.h"
|
2016-02-11 21:51:28 +01:00
|
|
|
#include "catalog/pg_constraint_fn.h"
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
#include "catalog/pg_depend.h"
|
|
|
|
#include "catalog/pg_inherits_fn.h"
|
2006-08-25 06:06:58 +02:00
|
|
|
#include "catalog/pg_operator.h"
|
2001-08-22 20:24:26 +02:00
|
|
|
#include "catalog/pg_opclass.h"
|
2007-10-12 20:55:12 +02:00
|
|
|
#include "catalog/pg_tablespace.h"
|
2009-07-29 22:56:21 +02:00
|
|
|
#include "catalog/pg_trigger.h"
|
1998-01-13 05:05:12 +01:00
|
|
|
#include "catalog/pg_type.h"
|
2008-11-19 11:34:52 +01:00
|
|
|
#include "catalog/storage.h"
|
2008-01-30 20:46:48 +01:00
|
|
|
#include "commands/tablecmds.h"
|
2009-07-29 22:56:21 +02:00
|
|
|
#include "commands/trigger.h"
|
1998-01-13 05:05:12 +01:00
|
|
|
#include "executor/executor.h"
|
|
|
|
#include "miscadmin.h"
|
2009-07-29 22:56:21 +02:00
|
|
|
#include "nodes/makefuncs.h"
|
2008-08-26 00:42:34 +02:00
|
|
|
#include "nodes/nodeFuncs.h"
|
1998-01-13 05:05:12 +01:00
|
|
|
#include "optimizer/clauses.h"
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
#include "optimizer/planner.h"
|
2009-07-29 22:56:21 +02:00
|
|
|
#include "parser/parser.h"
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
#include "rewrite/rewriteManip.h"
|
2008-05-12 02:00:54 +02:00
|
|
|
#include "storage/bufmgr.h"
|
|
|
|
#include "storage/lmgr.h"
|
2011-06-08 12:47:21 +02:00
|
|
|
#include "storage/predicate.h"
|
2005-05-19 23:35:48 +02:00
|
|
|
#include "storage/procarray.h"
|
1998-01-13 05:05:12 +01:00
|
|
|
#include "storage/smgr.h"
|
|
|
|
#include "utils/builtins.h"
|
2000-05-28 19:56:29 +02:00
|
|
|
#include "utils/fmgroids.h"
|
2011-09-04 07:13:16 +02:00
|
|
|
#include "utils/guc.h"
|
2000-11-08 23:10:03 +01:00
|
|
|
#include "utils/inval.h"
|
2002-03-26 20:17:02 +01:00
|
|
|
#include "utils/lsyscache.h"
|
2005-05-06 19:24:55 +02:00
|
|
|
#include "utils/memutils.h"
|
2015-05-15 13:09:57 +02:00
|
|
|
#include "utils/pg_rusage.h"
|
1998-01-13 05:05:12 +01:00
|
|
|
#include "utils/syscache.h"
|
2006-08-25 06:06:58 +02:00
|
|
|
#include "utils/tuplesort.h"
|
2008-03-26 19:48:59 +01:00
|
|
|
#include "utils/snapmgr.h"
|
2008-03-26 22:10:39 +01:00
|
|
|
#include "utils/tqual.h"
|
1996-11-05 12:57:55 +01:00
|
|
|
|
2002-03-26 20:17:02 +01:00
|
|
|
|
2015-03-11 03:33:25 +01:00
|
|
|
/* Potentially set by pg_upgrade_support functions */
|
2011-01-08 03:25:34 +01:00
|
|
|
Oid binary_upgrade_next_index_pg_class_oid = InvalidOid;
|
2010-02-03 02:14:17 +01:00
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
/* state info for validate_index bulkdelete callback */
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
Tuplesortstate *tuplesort; /* for sorting the index TIDs */
|
|
|
|
/* statistics (for debug purposes only): */
|
2006-10-04 02:30:14 +02:00
|
|
|
double htups,
|
|
|
|
itups,
|
|
|
|
tups_inserted;
|
2006-08-25 06:06:58 +02:00
|
|
|
} v_i_state;
|
|
|
|
|
2018-01-19 13:48:44 +01:00
|
|
|
/*
|
|
|
|
* Pointer-free representation of variables used when reindexing system
|
|
|
|
* catalogs; we use this to propagate those values to parallel workers.
|
|
|
|
*/
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
Oid currentlyReindexedHeap;
|
|
|
|
Oid currentlyReindexedIndex;
|
|
|
|
int numPendingReindexedIndexes;
|
|
|
|
Oid pendingReindexedIndexes[FLEXIBLE_ARRAY_MEMBER];
|
|
|
|
} SerializedReindexState;
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* non-export function prototypes */
|
2011-01-25 21:42:03 +01:00
|
|
|
static bool relationHasPrimaryKey(Relation rel);
|
2001-01-24 01:06:07 +01:00
|
|
|
static TupleDesc ConstructTupleDescriptor(Relation heapRelation,
|
2003-08-04 02:43:34 +02:00
|
|
|
IndexInfo *indexInfo,
|
Adjust naming of indexes and their columns per recent discussion.
Index expression columns are now named after the FigureColname result for
their expressions, rather than always being "pg_expression_N". Digits are
appended to this name if needed to make the column name unique within the
index. (That happens for regular columns too, thus fixing the old problem
that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes
there was no real reason to do such a thing, but now maybe there is.)
Default names for indexes and associated constraints now include the column
names of all their columns, not only the first one as in previous practice.
(Of course, this will be truncated as needed to fit in NAMEDATALEN. Also,
pkey indexes retain the historical behavior of not naming specific columns
at all.)
An example of the results:
regression=# create table foo (f1 int, f2 text,
regression(# exclude (f1 with =, lower(f2) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo"
CREATE TABLE
regression=# \d foo_f1_lower_exclusion
Index "public.foo_f1_lower_exclusion"
Column | Type | Definition
--------+---------+------------
f1 | integer | f1
lower | text | lower(f2)
btree, for table "public.foo"
2009-12-23 03:35:25 +01:00
|
|
|
List *indexColNames,
|
2008-09-15 20:43:41 +02:00
|
|
|
Oid accessMethodObjectId,
|
2011-02-08 22:04:18 +01:00
|
|
|
Oid *collationObjectId,
|
2003-08-04 02:43:34 +02:00
|
|
|
Oid *classObjectId);
|
1998-09-01 06:40:42 +02:00
|
|
|
static void InitializeAttributeOids(Relation indexRelation,
|
2000-04-12 19:17:23 +02:00
|
|
|
int numatts, Oid indexoid);
|
1999-11-01 03:29:27 +01:00
|
|
|
static void AppendAttributeTuples(Relation indexRelation, int numatts);
|
1998-09-01 06:40:42 +02:00
|
|
|
static void UpdateIndexRelation(Oid indexoid, Oid heapoid,
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
Oid parentIndexId,
|
2001-10-25 07:50:21 +02:00
|
|
|
IndexInfo *indexInfo,
|
2011-02-08 22:04:18 +01:00
|
|
|
Oid *collationOids,
|
2001-10-25 07:50:21 +02:00
|
|
|
Oid *classOids,
|
2007-01-09 03:14:16 +01:00
|
|
|
int16 *coloptions,
|
2006-08-25 06:06:58 +02:00
|
|
|
bool primary,
|
2011-01-25 23:51:59 +01:00
|
|
|
bool isexclusion,
|
2009-07-29 22:56:21 +02:00
|
|
|
bool immediate,
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
bool isvalid,
|
|
|
|
bool isready);
|
2009-12-07 06:22:23 +01:00
|
|
|
static void index_update_stats(Relation rel,
|
2011-01-25 23:51:59 +01:00
|
|
|
bool hasindex, bool isprimary,
|
2013-07-03 20:24:09 +02:00
|
|
|
double reltuples);
|
2009-12-07 06:22:23 +01:00
|
|
|
static void IndexCheckExclusion(Relation heapRelation,
|
|
|
|
Relation indexRelation,
|
|
|
|
IndexInfo *indexInfo);
|
2015-12-16 21:23:45 +01:00
|
|
|
static inline int64 itemptr_encode(ItemPointer itemptr);
|
|
|
|
static inline void itemptr_decode(ItemPointer itemptr, int64 encoded);
|
2006-08-25 06:06:58 +02:00
|
|
|
static bool validate_index_callback(ItemPointer itemptr, void *opaque);
|
|
|
|
static void validate_index_heapscan(Relation heapRelation,
|
|
|
|
Relation indexRelation,
|
|
|
|
IndexInfo *indexInfo,
|
|
|
|
Snapshot snapshot,
|
|
|
|
v_i_state *state);
|
2011-06-06 04:30:04 +02:00
|
|
|
static bool ReindexIsCurrentlyProcessingIndex(Oid indexOid);
|
2010-02-07 21:48:13 +01:00
|
|
|
static void SetReindexProcessing(Oid heapOid, Oid indexOid);
|
|
|
|
static void ResetReindexProcessing(void);
|
|
|
|
static void SetReindexPending(List *indexes);
|
|
|
|
static void RemoveReindexPending(Oid indexOid);
|
|
|
|
static void ResetReindexPending(void);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-15 00:18:02 +02:00
|
|
|
|
2011-01-25 21:42:03 +01:00
|
|
|
/*
|
|
|
|
* relationHasPrimaryKey
|
|
|
|
* See whether an existing relation has a primary key.
|
|
|
|
*
|
|
|
|
* Caller must have suitable lock on the relation.
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
*
|
|
|
|
* Note: we intentionally do not check IndexIsValid here; that's because this
|
|
|
|
* is used to enforce the rule that there can be only one indisprimary index,
|
|
|
|
* and we want that to be true even if said index is invalid.
|
2011-01-25 21:42:03 +01:00
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
relationHasPrimaryKey(Relation rel)
|
|
|
|
{
|
|
|
|
bool result = false;
|
|
|
|
List *indexoidlist;
|
|
|
|
ListCell *indexoidscan;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the list of index OIDs for the table from the relcache, and look up
|
|
|
|
* each one in the pg_index syscache until we find one marked primary key
|
|
|
|
* (hopefully there isn't more than one such).
|
|
|
|
*/
|
|
|
|
indexoidlist = RelationGetIndexList(rel);
|
|
|
|
|
|
|
|
foreach(indexoidscan, indexoidlist)
|
|
|
|
{
|
|
|
|
Oid indexoid = lfirst_oid(indexoidscan);
|
|
|
|
HeapTuple indexTuple;
|
|
|
|
|
|
|
|
indexTuple = SearchSysCache1(INDEXRELID, ObjectIdGetDatum(indexoid));
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
if (!HeapTupleIsValid(indexTuple)) /* should not happen */
|
2011-01-25 21:42:03 +01:00
|
|
|
elog(ERROR, "cache lookup failed for index %u", indexoid);
|
|
|
|
result = ((Form_pg_index) GETSTRUCT(indexTuple))->indisprimary;
|
|
|
|
ReleaseSysCache(indexTuple);
|
|
|
|
if (result)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_free(indexoidlist);
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* index_check_primary_key
|
|
|
|
* Apply special checks needed before creating a PRIMARY KEY index
|
|
|
|
*
|
|
|
|
* This processing used to be in DefineIndex(), but has been split out
|
|
|
|
* so that it can be applied during ALTER TABLE ADD PRIMARY KEY USING INDEX.
|
|
|
|
*
|
|
|
|
* We check for a pre-existing primary key, and that all columns of the index
|
|
|
|
* are simple column references (not expressions), and that all those
|
|
|
|
* columns are marked NOT NULL. If they aren't (which can only happen during
|
|
|
|
* ALTER TABLE ADD CONSTRAINT, since the parser forces such columns to be
|
|
|
|
* created NOT NULL during CREATE TABLE), do an ALTER SET NOT NULL to mark
|
|
|
|
* them so --- or fail if they are not in fact nonnull.
|
|
|
|
*
|
2017-08-04 17:45:18 +02:00
|
|
|
* As of PG v10, the SET NOT NULL is applied to child tables as well, so
|
|
|
|
* that the behavior is like a manual SET NOT NULL.
|
|
|
|
*
|
2011-01-25 21:42:03 +01:00
|
|
|
* Caller had better have at least ShareLock on the table, else the not-null
|
|
|
|
* checking isn't trustworthy.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
index_check_primary_key(Relation heapRel,
|
|
|
|
IndexInfo *indexInfo,
|
|
|
|
bool is_alter_table)
|
|
|
|
{
|
|
|
|
List *cmds;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* If ALTER TABLE, check that there isn't already a PRIMARY KEY. In CREATE
|
|
|
|
* TABLE, we have faith that the parser rejected multiple pkey clauses;
|
|
|
|
* and CREATE INDEX doesn't have a way to say PRIMARY KEY, so it's no
|
|
|
|
* problem either.
|
2011-01-25 21:42:03 +01:00
|
|
|
*/
|
|
|
|
if (is_alter_table &&
|
|
|
|
relationHasPrimaryKey(heapRel))
|
|
|
|
{
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
errmsg("multiple primary keys for table \"%s\" are not allowed",
|
|
|
|
RelationGetRelationName(heapRel))));
|
2011-01-25 21:42:03 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check that all of the attributes in a primary key are marked as not
|
|
|
|
* null, otherwise attempt to ALTER TABLE .. SET NOT NULL
|
|
|
|
*/
|
|
|
|
cmds = NIL;
|
2016-04-08 20:52:13 +02:00
|
|
|
for (i = 0; i < indexInfo->ii_NumIndexAttrs; i++)
|
2011-01-25 21:42:03 +01:00
|
|
|
{
|
|
|
|
AttrNumber attnum = indexInfo->ii_KeyAttrNumbers[i];
|
|
|
|
HeapTuple atttuple;
|
|
|
|
Form_pg_attribute attform;
|
|
|
|
|
|
|
|
if (attnum == 0)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("primary keys cannot be expressions")));
|
|
|
|
|
|
|
|
/* System attributes are never null, so no need to check */
|
|
|
|
if (attnum < 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
atttuple = SearchSysCache2(ATTNUM,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
ObjectIdGetDatum(RelationGetRelid(heapRel)),
|
2011-01-25 21:42:03 +01:00
|
|
|
Int16GetDatum(attnum));
|
|
|
|
if (!HeapTupleIsValid(atttuple))
|
|
|
|
elog(ERROR, "cache lookup failed for attribute %d of relation %u",
|
|
|
|
attnum, RelationGetRelid(heapRel));
|
|
|
|
attform = (Form_pg_attribute) GETSTRUCT(atttuple);
|
|
|
|
|
|
|
|
if (!attform->attnotnull)
|
|
|
|
{
|
|
|
|
/* Add a subcommand to make this one NOT NULL */
|
|
|
|
AlterTableCmd *cmd = makeNode(AlterTableCmd);
|
|
|
|
|
|
|
|
cmd->subtype = AT_SetNotNull;
|
|
|
|
cmd->name = pstrdup(NameStr(attform->attname));
|
|
|
|
cmds = lappend(cmds, cmd);
|
|
|
|
}
|
|
|
|
|
|
|
|
ReleaseSysCache(atttuple);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* XXX: possible future improvement: when being called from ALTER TABLE,
|
|
|
|
* it would be more efficient to merge this with the outer ALTER TABLE, so
|
|
|
|
* as to avoid two scans. But that seems to complicate DefineIndex's API
|
|
|
|
* unduly.
|
2011-01-25 21:42:03 +01:00
|
|
|
*/
|
|
|
|
if (cmds)
|
2017-08-04 17:45:18 +02:00
|
|
|
AlterTableInternal(RelationGetRelid(heapRel), cmds, true);
|
2011-01-25 21:42:03 +01:00
|
|
|
}
|
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
* ConstructTupleDescriptor
|
2000-07-15 00:18:02 +02:00
|
|
|
*
|
2003-05-28 18:04:02 +02:00
|
|
|
* Build an index tuple descriptor for a new index
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-08 04:41:22 +02:00
|
|
|
static TupleDesc
|
2001-01-24 01:06:07 +01:00
|
|
|
ConstructTupleDescriptor(Relation heapRelation,
|
2003-05-28 18:04:02 +02:00
|
|
|
IndexInfo *indexInfo,
|
Adjust naming of indexes and their columns per recent discussion.
Index expression columns are now named after the FigureColname result for
their expressions, rather than always being "pg_expression_N". Digits are
appended to this name if needed to make the column name unique within the
index. (That happens for regular columns too, thus fixing the old problem
that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes
there was no real reason to do such a thing, but now maybe there is.)
Default names for indexes and associated constraints now include the column
names of all their columns, not only the first one as in previous practice.
(Of course, this will be truncated as needed to fit in NAMEDATALEN. Also,
pkey indexes retain the historical behavior of not naming specific columns
at all.)
An example of the results:
regression=# create table foo (f1 int, f2 text,
regression(# exclude (f1 with =, lower(f2) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo"
CREATE TABLE
regression=# \d foo_f1_lower_exclusion
Index "public.foo_f1_lower_exclusion"
Column | Type | Definition
--------+---------+------------
f1 | integer | f1
lower | text | lower(f2)
btree, for table "public.foo"
2009-12-23 03:35:25 +01:00
|
|
|
List *indexColNames,
|
2008-09-15 20:43:41 +02:00
|
|
|
Oid accessMethodObjectId,
|
2011-02-08 22:04:18 +01:00
|
|
|
Oid *collationObjectId,
|
2001-08-22 20:24:26 +02:00
|
|
|
Oid *classObjectId)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2003-05-28 18:04:02 +02:00
|
|
|
int numatts = indexInfo->ii_NumIndexAttrs;
|
Adjust naming of indexes and their columns per recent discussion.
Index expression columns are now named after the FigureColname result for
their expressions, rather than always being "pg_expression_N". Digits are
appended to this name if needed to make the column name unique within the
index. (That happens for regular columns too, thus fixing the old problem
that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes
there was no real reason to do such a thing, but now maybe there is.)
Default names for indexes and associated constraints now include the column
names of all their columns, not only the first one as in previous practice.
(Of course, this will be truncated as needed to fit in NAMEDATALEN. Also,
pkey indexes retain the historical behavior of not naming specific columns
at all.)
An example of the results:
regression=# create table foo (f1 int, f2 text,
regression(# exclude (f1 with =, lower(f2) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo"
CREATE TABLE
regression=# \d foo_f1_lower_exclusion
Index "public.foo_f1_lower_exclusion"
Column | Type | Definition
--------+---------+------------
f1 | integer | f1
lower | text | lower(f2)
btree, for table "public.foo"
2009-12-23 03:35:25 +01:00
|
|
|
ListCell *colnames_item = list_head(indexColNames);
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *indexpr_item = list_head(indexInfo->ii_Expressions);
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
IndexAmRoutine *amroutine;
|
1997-09-08 04:41:22 +02:00
|
|
|
TupleDesc heapTupDesc;
|
|
|
|
TupleDesc indexTupDesc;
|
2000-07-15 00:18:02 +02:00
|
|
|
int natts; /* #atts in heap rel --- for error checks */
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
/* We need access to the index AM's API struct */
|
2016-08-14 00:31:14 +02:00
|
|
|
amroutine = GetIndexAmRoutineByAmId(accessMethodObjectId, false);
|
2008-09-15 20:43:41 +02:00
|
|
|
|
|
|
|
/* ... and to the table's tuple descriptor */
|
2000-07-15 00:18:02 +02:00
|
|
|
heapTupDesc = RelationGetDescr(heapRelation);
|
|
|
|
natts = RelationGetForm(heapRelation)->relnatts;
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* allocate the new tuple descriptor
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2002-09-02 03:05:06 +02:00
|
|
|
indexTupDesc = CreateTemplateTupleDesc(numatts, false);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* For simple index columns, we copy the pg_attribute row from the parent
|
|
|
|
* relation and modify it as necessary. For expressions we have to cons
|
|
|
|
* up a pg_attribute row the hard way.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-07-15 00:18:02 +02:00
|
|
|
for (i = 0; i < numatts; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2003-05-28 18:04:02 +02:00
|
|
|
AttrNumber atnum = indexInfo->ii_KeyAttrNumbers[i];
|
2017-08-20 20:19:07 +02:00
|
|
|
Form_pg_attribute to = TupleDescAttr(indexTupDesc, i);
|
2001-08-22 20:24:26 +02:00
|
|
|
HeapTuple tuple;
|
2003-05-28 18:04:02 +02:00
|
|
|
Form_pg_type typeTup;
|
2008-09-15 20:43:41 +02:00
|
|
|
Form_pg_opclass opclassTup;
|
2001-08-22 20:24:26 +02:00
|
|
|
Oid keyType;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
if (atnum != 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2003-05-28 18:04:02 +02:00
|
|
|
/* Simple index column */
|
|
|
|
Form_pg_attribute from;
|
|
|
|
|
|
|
|
if (atnum < 0)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* here we are indexing on a system attribute (-1...-n)
|
|
|
|
*/
|
|
|
|
from = SystemAttributeDefinition(atnum,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
heapRelation->rd_rel->relhasoids);
|
2003-05-28 18:04:02 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* here we are indexing on a normal attribute (1...n)
|
|
|
|
*/
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
if (atnum > natts) /* safety check */
|
2003-07-21 03:59:11 +02:00
|
|
|
elog(ERROR, "invalid column number %d", atnum);
|
2017-08-20 20:19:07 +02:00
|
|
|
from = TupleDescAttr(heapTupDesc,
|
|
|
|
AttrNumberGetAttrOffset(atnum));
|
2003-05-28 18:04:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* now that we've determined the "from", let's copy the tuple desc
|
|
|
|
* data...
|
2003-05-28 18:04:02 +02:00
|
|
|
*/
|
2009-01-22 21:16:10 +01:00
|
|
|
memcpy(to, from, ATTRIBUTE_FIXED_PART_SIZE);
|
2003-05-28 18:04:02 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2003-05-28 18:04:02 +02:00
|
|
|
* Fix the stuff that should not be the same as the underlying
|
|
|
|
* attr
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2003-05-28 18:04:02 +02:00
|
|
|
to->attnum = i + 1;
|
|
|
|
|
2004-02-15 22:01:39 +01:00
|
|
|
to->attstattarget = -1;
|
2003-05-28 18:04:02 +02:00
|
|
|
to->attcacheoff = -1;
|
|
|
|
to->attnotnull = false;
|
|
|
|
to->atthasdef = false;
|
2017-04-06 14:33:16 +02:00
|
|
|
to->attidentity = '\0';
|
2003-05-28 18:04:02 +02:00
|
|
|
to->attislocal = true;
|
|
|
|
to->attinhcount = 0;
|
2011-03-04 22:39:44 +01:00
|
|
|
to->attcollation = collationObjectId[i];
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2003-05-28 18:04:02 +02:00
|
|
|
/* Expressional index */
|
|
|
|
Node *indexkey;
|
|
|
|
|
2009-01-22 21:16:10 +01:00
|
|
|
MemSet(to, 0, ATTRIBUTE_FIXED_PART_SIZE);
|
2005-03-07 05:42:17 +01:00
|
|
|
|
2004-05-26 06:41:50 +02:00
|
|
|
if (indexpr_item == NULL) /* shouldn't happen */
|
2003-05-28 18:04:02 +02:00
|
|
|
elog(ERROR, "too few entries in indexprs list");
|
2004-05-26 06:41:50 +02:00
|
|
|
indexkey = (Node *) lfirst(indexpr_item);
|
|
|
|
indexpr_item = lnext(indexpr_item);
|
2003-05-28 18:04:02 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Lookup the expression type in pg_type for the type length etc.
|
2003-05-28 18:04:02 +02:00
|
|
|
*/
|
|
|
|
keyType = exprType(indexkey);
|
2010-02-14 19:42:19 +01:00
|
|
|
tuple = SearchSysCache1(TYPEOID, ObjectIdGetDatum(keyType));
|
2003-05-28 18:04:02 +02:00
|
|
|
if (!HeapTupleIsValid(tuple))
|
2003-07-21 03:59:11 +02:00
|
|
|
elog(ERROR, "cache lookup failed for type %u", keyType);
|
2003-05-28 18:04:02 +02:00
|
|
|
typeTup = (Form_pg_type) GETSTRUCT(tuple);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/*
|
|
|
|
* Assign some of the attributes values. Leave the rest as 0.
|
|
|
|
*/
|
|
|
|
to->attnum = i + 1;
|
|
|
|
to->atttypid = keyType;
|
|
|
|
to->attlen = typeTup->typlen;
|
|
|
|
to->attbyval = typeTup->typbyval;
|
|
|
|
to->attstorage = typeTup->typstorage;
|
|
|
|
to->attalign = typeTup->typalign;
|
2004-02-15 22:01:39 +01:00
|
|
|
to->attstattarget = -1;
|
2003-05-28 18:04:02 +02:00
|
|
|
to->attcacheoff = -1;
|
2014-04-26 18:22:09 +02:00
|
|
|
to->atttypmod = exprTypmod(indexkey);
|
2003-05-28 18:04:02 +02:00
|
|
|
to->attislocal = true;
|
2011-03-04 22:39:44 +01:00
|
|
|
to->attcollation = collationObjectId[i];
|
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
ReleaseSysCache(tuple);
|
2008-10-14 23:47:39 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure the expression yields a type that's safe to store in
|
|
|
|
* an index. We need this defense because we have index opclasses
|
|
|
|
* for pseudo-types such as "record", and the actually stored type
|
|
|
|
* had better be safe; eg, a named composite type is okay, an
|
|
|
|
* anonymous record type is not. The test is the same as for
|
|
|
|
* whether a table column is of a safe type (which is why we
|
|
|
|
* needn't check for the non-expression case).
|
|
|
|
*/
|
2011-03-28 21:44:54 +02:00
|
|
|
CheckAttributeType(NameStr(to->attname),
|
|
|
|
to->atttypid, to->attcollation,
|
|
|
|
NIL, false);
|
2003-05-28 18:04:02 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-01-24 01:06:07 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* We do not yet have the correct relation OID for the index, so just
|
2014-05-06 18:12:18 +02:00
|
|
|
* set it invalid for now. InitializeAttributeOids() will fix it
|
2005-10-15 04:49:52 +02:00
|
|
|
* later.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2001-01-24 01:06:07 +01:00
|
|
|
to->attrelid = InvalidOid;
|
2001-08-22 20:24:26 +02:00
|
|
|
|
Adjust naming of indexes and their columns per recent discussion.
Index expression columns are now named after the FigureColname result for
their expressions, rather than always being "pg_expression_N". Digits are
appended to this name if needed to make the column name unique within the
index. (That happens for regular columns too, thus fixing the old problem
that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes
there was no real reason to do such a thing, but now maybe there is.)
Default names for indexes and associated constraints now include the column
names of all their columns, not only the first one as in previous practice.
(Of course, this will be truncated as needed to fit in NAMEDATALEN. Also,
pkey indexes retain the historical behavior of not naming specific columns
at all.)
An example of the results:
regression=# create table foo (f1 int, f2 text,
regression(# exclude (f1 with =, lower(f2) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo"
CREATE TABLE
regression=# \d foo_f1_lower_exclusion
Index "public.foo_f1_lower_exclusion"
Column | Type | Definition
--------+---------+------------
f1 | integer | f1
lower | text | lower(f2)
btree, for table "public.foo"
2009-12-23 03:35:25 +01:00
|
|
|
/*
|
|
|
|
* Set the attribute name as specified by caller.
|
|
|
|
*/
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
if (colnames_item == NULL) /* shouldn't happen */
|
Adjust naming of indexes and their columns per recent discussion.
Index expression columns are now named after the FigureColname result for
their expressions, rather than always being "pg_expression_N". Digits are
appended to this name if needed to make the column name unique within the
index. (That happens for regular columns too, thus fixing the old problem
that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes
there was no real reason to do such a thing, but now maybe there is.)
Default names for indexes and associated constraints now include the column
names of all their columns, not only the first one as in previous practice.
(Of course, this will be truncated as needed to fit in NAMEDATALEN. Also,
pkey indexes retain the historical behavior of not naming specific columns
at all.)
An example of the results:
regression=# create table foo (f1 int, f2 text,
regression(# exclude (f1 with =, lower(f2) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo"
CREATE TABLE
regression=# \d foo_f1_lower_exclusion
Index "public.foo_f1_lower_exclusion"
Column | Type | Definition
--------+---------+------------
f1 | integer | f1
lower | text | lower(f2)
btree, for table "public.foo"
2009-12-23 03:35:25 +01:00
|
|
|
elog(ERROR, "too few entries in colnames list");
|
|
|
|
namestrcpy(&to->attname, (const char *) lfirst(colnames_item));
|
|
|
|
colnames_item = lnext(colnames_item);
|
|
|
|
|
2001-08-22 20:24:26 +02:00
|
|
|
/*
|
2008-09-15 20:43:41 +02:00
|
|
|
* Check the opclass and index AM to see if either provides a keytype
|
|
|
|
* (overriding the attribute type). Opclass takes precedence.
|
2001-08-22 20:24:26 +02:00
|
|
|
*/
|
2010-02-14 19:42:19 +01:00
|
|
|
tuple = SearchSysCache1(CLAOID, ObjectIdGetDatum(classObjectId[i]));
|
2001-08-22 20:24:26 +02:00
|
|
|
if (!HeapTupleIsValid(tuple))
|
2003-07-21 03:59:11 +02:00
|
|
|
elog(ERROR, "cache lookup failed for opclass %u",
|
|
|
|
classObjectId[i]);
|
2008-09-15 20:43:41 +02:00
|
|
|
opclassTup = (Form_pg_opclass) GETSTRUCT(tuple);
|
|
|
|
if (OidIsValid(opclassTup->opckeytype))
|
|
|
|
keyType = opclassTup->opckeytype;
|
|
|
|
else
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
keyType = amroutine->amkeytype;
|
Replace the built-in GIN array opclasses with a single polymorphic opclass.
We had thirty different GIN array opclasses sharing the same operators and
support functions. That still didn't cover all the built-in types, nor
did it cover arrays of extension-added types. What we want is a single
polymorphic opclass for "anyarray". There were two missing features needed
to make this possible:
1. We have to be able to declare the index storage type as ANYELEMENT
when the opclass is declared to index ANYARRAY. This just takes a few
more lines in index_create(). Although this currently seems of use only
for GIN, there's no reason to make index_create() restrict it to that.
2. We have to be able to identify the proper GIN compare function for
the index storage type. This patch proceeds by making the compare function
optional in GIN opclass definitions, and specifying that the default btree
comparison function for the index storage type will be looked up when the
opclass omits it. Again, that seems pretty generically useful.
Since the comparison function lookup is done in initGinState(), making
use of the second feature adds an additional cache lookup to GIN index
access setup. It seems unlikely that that would be very noticeable given
the other costs involved, but maybe at some point we should consider
making GinState data persist longer than it now does --- we could keep it
in the index relcache entry, perhaps.
Rather fortuitously, we don't seem to need to do anything to get this
change to play nice with dump/reload or pg_upgrade scenarios: the new
opclass definition is automatically selected to replace existing index
definitions, and the on-disk data remains compatible. Also, if a user has
created a custom opclass definition for a non-builtin type, this doesn't
break that, since CREATE INDEX will prefer an exact match to opcintype
over a match to ANYARRAY. However, if there's anyone out there with
handwritten DDL that explicitly specifies _bool_ops or one of the other
replaced opclass names, they'll need to adjust that.
Tom Lane, reviewed by Enrique Meneses
Discussion: <14436.1470940379@sss.pgh.pa.us>
2016-09-26 20:52:44 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If keytype is specified as ANYELEMENT, and opcintype is ANYARRAY,
|
|
|
|
* then the attribute type must be an array (else it'd not have
|
|
|
|
* matched this opclass); use its element type.
|
|
|
|
*/
|
|
|
|
if (keyType == ANYELEMENTOID && opclassTup->opcintype == ANYARRAYOID)
|
|
|
|
{
|
|
|
|
keyType = get_base_element_type(to->atttypid);
|
|
|
|
if (!OidIsValid(keyType))
|
|
|
|
elog(ERROR, "could not get element type of array type %u",
|
|
|
|
to->atttypid);
|
|
|
|
}
|
|
|
|
|
2001-08-22 20:24:26 +02:00
|
|
|
ReleaseSysCache(tuple);
|
|
|
|
|
Replace the built-in GIN array opclasses with a single polymorphic opclass.
We had thirty different GIN array opclasses sharing the same operators and
support functions. That still didn't cover all the built-in types, nor
did it cover arrays of extension-added types. What we want is a single
polymorphic opclass for "anyarray". There were two missing features needed
to make this possible:
1. We have to be able to declare the index storage type as ANYELEMENT
when the opclass is declared to index ANYARRAY. This just takes a few
more lines in index_create(). Although this currently seems of use only
for GIN, there's no reason to make index_create() restrict it to that.
2. We have to be able to identify the proper GIN compare function for
the index storage type. This patch proceeds by making the compare function
optional in GIN opclass definitions, and specifying that the default btree
comparison function for the index storage type will be looked up when the
opclass omits it. Again, that seems pretty generically useful.
Since the comparison function lookup is done in initGinState(), making
use of the second feature adds an additional cache lookup to GIN index
access setup. It seems unlikely that that would be very noticeable given
the other costs involved, but maybe at some point we should consider
making GinState data persist longer than it now does --- we could keep it
in the index relcache entry, perhaps.
Rather fortuitously, we don't seem to need to do anything to get this
change to play nice with dump/reload or pg_upgrade scenarios: the new
opclass definition is automatically selected to replace existing index
definitions, and the on-disk data remains compatible. Also, if a user has
created a custom opclass definition for a non-builtin type, this doesn't
break that, since CREATE INDEX will prefer an exact match to opcintype
over a match to ANYARRAY. However, if there's anyone out there with
handwritten DDL that explicitly specifies _bool_ops or one of the other
replaced opclass names, they'll need to adjust that.
Tom Lane, reviewed by Enrique Meneses
Discussion: <14436.1470940379@sss.pgh.pa.us>
2016-09-26 20:52:44 +02:00
|
|
|
/*
|
|
|
|
* If a key type different from the heap value is specified, update
|
|
|
|
* the type-related fields in the index tupdesc.
|
|
|
|
*/
|
2001-08-22 20:24:26 +02:00
|
|
|
if (OidIsValid(keyType) && keyType != to->atttypid)
|
|
|
|
{
|
2010-02-14 19:42:19 +01:00
|
|
|
tuple = SearchSysCache1(TYPEOID, ObjectIdGetDatum(keyType));
|
2001-08-22 20:24:26 +02:00
|
|
|
if (!HeapTupleIsValid(tuple))
|
2003-07-21 03:59:11 +02:00
|
|
|
elog(ERROR, "cache lookup failed for type %u", keyType);
|
2001-08-22 20:24:26 +02:00
|
|
|
typeTup = (Form_pg_type) GETSTRUCT(tuple);
|
|
|
|
|
2001-10-25 07:50:21 +02:00
|
|
|
to->atttypid = keyType;
|
|
|
|
to->atttypmod = -1;
|
|
|
|
to->attlen = typeTup->typlen;
|
|
|
|
to->attbyval = typeTup->typbyval;
|
|
|
|
to->attalign = typeTup->typalign;
|
2001-08-22 20:24:26 +02:00
|
|
|
to->attstorage = typeTup->typstorage;
|
|
|
|
|
|
|
|
ReleaseSysCache(tuple);
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
pfree(amroutine);
|
2008-09-15 20:43:41 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
return indexTupDesc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* InitializeAttributeOids
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
InitializeAttributeOids(Relation indexRelation,
|
|
|
|
int numatts,
|
|
|
|
Oid indexoid)
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
TupleDesc tupleDescriptor;
|
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
tupleDescriptor = RelationGetDescr(indexRelation);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
for (i = 0; i < numatts; i += 1)
|
2017-08-20 20:19:07 +02:00
|
|
|
TupleDescAttr(tupleDescriptor, i)->attrelid = indexoid;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* AppendAttributeTuples
|
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
AppendAttributeTuples(Relation indexRelation, int numatts)
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Relation pg_attribute;
|
2002-08-05 05:29:17 +02:00
|
|
|
CatalogIndexState indstate;
|
1997-09-08 04:41:22 +02:00
|
|
|
TupleDesc indexTupDesc;
|
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2002-08-05 05:29:17 +02:00
|
|
|
* open the attribute relation and its indexes
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2005-04-14 22:03:27 +02:00
|
|
|
pg_attribute = heap_open(AttributeRelationId, RowExclusiveLock);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-08-05 05:29:17 +02:00
|
|
|
indstate = CatalogOpenIndexes(pg_attribute);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2001-06-12 07:55:50 +02:00
|
|
|
* insert data from new index's tupdesc into pg_attribute
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
1998-09-01 05:29:17 +02:00
|
|
|
indexTupDesc = RelationGetDescr(indexRelation);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-06-12 07:55:50 +02:00
|
|
|
for (i = 0; i < numatts; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2017-08-20 20:19:07 +02:00
|
|
|
Form_pg_attribute attr = TupleDescAttr(indexTupDesc, i);
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* There used to be very grotty code here to set these fields, but I
|
|
|
|
* think it's unnecessary. They should be set already.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2017-08-20 20:19:07 +02:00
|
|
|
Assert(attr->attnum == i + 1);
|
|
|
|
Assert(attr->attcacheoff == -1);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2017-08-20 20:19:07 +02:00
|
|
|
InsertPgAttributeTuple(pg_attribute, attr, indstate);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
2002-08-05 05:29:17 +02:00
|
|
|
CatalogCloseIndexes(indstate);
|
2001-06-12 07:55:50 +02:00
|
|
|
|
|
|
|
heap_close(pg_attribute, RowExclusiveLock);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* UpdateIndexRelation
|
2006-08-25 06:06:58 +02:00
|
|
|
*
|
|
|
|
* Construct and insert a new entry in the pg_index catalog
|
1997-09-07 07:04:48 +02:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
UpdateIndexRelation(Oid indexoid,
|
|
|
|
Oid heapoid,
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
Oid parentIndexOid,
|
2000-07-15 00:18:02 +02:00
|
|
|
IndexInfo *indexInfo,
|
2011-02-08 22:04:18 +01:00
|
|
|
Oid *collationOids,
|
1998-09-01 05:29:17 +02:00
|
|
|
Oid *classOids,
|
2007-01-09 03:14:16 +01:00
|
|
|
int16 *coloptions,
|
2006-08-25 06:06:58 +02:00
|
|
|
bool primary,
|
2011-01-25 23:51:59 +01:00
|
|
|
bool isexclusion,
|
2009-07-29 22:56:21 +02:00
|
|
|
bool immediate,
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
bool isvalid,
|
|
|
|
bool isready)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-03-29 02:17:27 +02:00
|
|
|
int2vector *indkey;
|
2011-02-08 22:04:18 +01:00
|
|
|
oidvector *indcollation;
|
2005-03-29 02:17:27 +02:00
|
|
|
oidvector *indclass;
|
2007-01-09 03:14:16 +01:00
|
|
|
int2vector *indoption;
|
2003-05-28 18:04:02 +02:00
|
|
|
Datum exprsDatum;
|
2002-09-27 17:05:23 +02:00
|
|
|
Datum predDatum;
|
|
|
|
Datum values[Natts_pg_index];
|
2008-11-02 02:45:28 +01:00
|
|
|
bool nulls[Natts_pg_index];
|
1997-09-08 04:41:22 +02:00
|
|
|
Relation pg_index;
|
|
|
|
HeapTuple tuple;
|
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2007-01-09 03:14:16 +01:00
|
|
|
* Copy the index key, opclass, and indoption info into arrays (should we
|
|
|
|
* make the caller pass them like this to start with?)
|
2002-09-27 17:05:23 +02:00
|
|
|
*/
|
2005-03-29 02:17:27 +02:00
|
|
|
indkey = buildint2vector(NULL, indexInfo->ii_NumIndexAttrs);
|
2002-09-27 17:05:23 +02:00
|
|
|
for (i = 0; i < indexInfo->ii_NumIndexAttrs; i++)
|
2005-03-29 02:17:27 +02:00
|
|
|
indkey->values[i] = indexInfo->ii_KeyAttrNumbers[i];
|
2011-02-08 22:04:18 +01:00
|
|
|
indcollation = buildoidvector(collationOids, indexInfo->ii_NumIndexAttrs);
|
2016-04-08 20:52:13 +02:00
|
|
|
indclass = buildoidvector(classOids, indexInfo->ii_NumIndexAttrs);
|
2007-01-09 03:14:16 +01:00
|
|
|
indoption = buildint2vector(coloptions, indexInfo->ii_NumIndexAttrs);
|
2003-05-28 18:04:02 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Convert the index expressions (if any) to a text datum
|
|
|
|
*/
|
|
|
|
if (indexInfo->ii_Expressions != NIL)
|
|
|
|
{
|
|
|
|
char *exprsString;
|
|
|
|
|
|
|
|
exprsString = nodeToString(indexInfo->ii_Expressions);
|
2008-03-25 23:42:46 +01:00
|
|
|
exprsDatum = CStringGetTextDatum(exprsString);
|
2003-05-28 18:04:02 +02:00
|
|
|
pfree(exprsString);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
exprsDatum = (Datum) 0;
|
2002-09-27 17:05:23 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Convert the index predicate (if any) to a text datum. Note we convert
|
|
|
|
* implicit-AND format to normal explicit-AND for storage.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2001-07-16 07:07:00 +02:00
|
|
|
if (indexInfo->ii_Predicate != NIL)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2002-09-27 17:05:23 +02:00
|
|
|
char *predString;
|
|
|
|
|
2003-12-28 22:57:37 +01:00
|
|
|
predString = nodeToString(make_ands_explicit(indexInfo->ii_Predicate));
|
2008-03-25 23:42:46 +01:00
|
|
|
predDatum = CStringGetTextDatum(predString);
|
1997-09-07 07:04:48 +02:00
|
|
|
pfree(predString);
|
|
|
|
}
|
|
|
|
else
|
2003-05-28 18:04:02 +02:00
|
|
|
predDatum = (Datum) 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* open the system catalog index relation
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2005-04-14 22:03:27 +02:00
|
|
|
pg_index = heap_open(IndexRelationId, RowExclusiveLock);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2002-09-27 17:05:23 +02:00
|
|
|
* Build a pg_index tuple
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2008-11-02 02:45:28 +01:00
|
|
|
MemSet(nulls, false, sizeof(nulls));
|
2002-09-27 17:05:23 +02:00
|
|
|
|
|
|
|
values[Anum_pg_index_indexrelid - 1] = ObjectIdGetDatum(indexoid);
|
|
|
|
values[Anum_pg_index_indrelid - 1] = ObjectIdGetDatum(heapoid);
|
2003-05-28 18:04:02 +02:00
|
|
|
values[Anum_pg_index_indnatts - 1] = Int16GetDatum(indexInfo->ii_NumIndexAttrs);
|
2002-09-27 17:05:23 +02:00
|
|
|
values[Anum_pg_index_indisunique - 1] = BoolGetDatum(indexInfo->ii_Unique);
|
|
|
|
values[Anum_pg_index_indisprimary - 1] = BoolGetDatum(primary);
|
2011-01-25 23:51:59 +01:00
|
|
|
values[Anum_pg_index_indisexclusion - 1] = BoolGetDatum(isexclusion);
|
2009-07-29 22:56:21 +02:00
|
|
|
values[Anum_pg_index_indimmediate - 1] = BoolGetDatum(immediate);
|
2003-05-28 18:04:02 +02:00
|
|
|
values[Anum_pg_index_indisclustered - 1] = BoolGetDatum(false);
|
2006-08-25 06:06:58 +02:00
|
|
|
values[Anum_pg_index_indisvalid - 1] = BoolGetDatum(isvalid);
|
2007-09-20 19:56:33 +02:00
|
|
|
values[Anum_pg_index_indcheckxmin - 1] = BoolGetDatum(false);
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
values[Anum_pg_index_indisready - 1] = BoolGetDatum(isready);
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
values[Anum_pg_index_indislive - 1] = BoolGetDatum(true);
|
2013-11-08 18:30:43 +01:00
|
|
|
values[Anum_pg_index_indisreplident - 1] = BoolGetDatum(false);
|
2005-03-29 02:17:27 +02:00
|
|
|
values[Anum_pg_index_indkey - 1] = PointerGetDatum(indkey);
|
2011-02-08 22:04:18 +01:00
|
|
|
values[Anum_pg_index_indcollation - 1] = PointerGetDatum(indcollation);
|
2005-03-29 02:17:27 +02:00
|
|
|
values[Anum_pg_index_indclass - 1] = PointerGetDatum(indclass);
|
2007-01-09 03:14:16 +01:00
|
|
|
values[Anum_pg_index_indoption - 1] = PointerGetDatum(indoption);
|
2003-05-28 18:04:02 +02:00
|
|
|
values[Anum_pg_index_indexprs - 1] = exprsDatum;
|
|
|
|
if (exprsDatum == (Datum) 0)
|
2008-11-02 02:45:28 +01:00
|
|
|
nulls[Anum_pg_index_indexprs - 1] = true;
|
2002-09-27 17:05:23 +02:00
|
|
|
values[Anum_pg_index_indpred - 1] = predDatum;
|
2003-05-28 18:04:02 +02:00
|
|
|
if (predDatum == (Datum) 0)
|
2008-11-02 02:45:28 +01:00
|
|
|
nulls[Anum_pg_index_indpred - 1] = true;
|
2002-09-27 17:05:23 +02:00
|
|
|
|
2008-11-02 02:45:28 +01:00
|
|
|
tuple = heap_form_tuple(RelationGetDescr(pg_index), values, nulls);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2002-08-05 05:29:17 +02:00
|
|
|
* insert the tuple into the pg_index catalog
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleInsert(pg_index, tuple);
|
2000-07-15 00:18:02 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* close the relation and free the tuple
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
1999-09-18 21:08:25 +02:00
|
|
|
heap_close(pg_index, RowExclusiveLock);
|
1999-12-16 23:20:03 +01:00
|
|
|
heap_freetuple(tuple);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-05-11 01:18:39 +02:00
|
|
|
/*
|
|
|
|
* index_create
|
2001-08-10 20:57:42 +02:00
|
|
|
*
|
2011-01-25 21:42:03 +01:00
|
|
|
* heapRelation: table to build index on (suitably locked by caller)
|
2006-05-11 01:18:39 +02:00
|
|
|
* indexRelationName: what it say
|
|
|
|
* indexRelationId: normally, pass InvalidOid to let this routine
|
2014-05-06 18:12:18 +02:00
|
|
|
* generate an OID for the index. During bootstrap this may be
|
2005-04-14 03:38:22 +02:00
|
|
|
* nonzero to specify a preselected OID.
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
* parentIndexRelid: if creating an index partition, the OID of the
|
|
|
|
* parent index; otherwise InvalidOid.
|
2011-07-18 17:02:48 +02:00
|
|
|
* relFileNode: normally, pass InvalidOid to get new storage. May be
|
|
|
|
* nonzero to attach an existing valid build.
|
2006-05-11 01:18:39 +02:00
|
|
|
* indexInfo: same info executor uses to insert into the index
|
Adjust naming of indexes and their columns per recent discussion.
Index expression columns are now named after the FigureColname result for
their expressions, rather than always being "pg_expression_N". Digits are
appended to this name if needed to make the column name unique within the
index. (That happens for regular columns too, thus fixing the old problem
that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes
there was no real reason to do such a thing, but now maybe there is.)
Default names for indexes and associated constraints now include the column
names of all their columns, not only the first one as in previous practice.
(Of course, this will be truncated as needed to fit in NAMEDATALEN. Also,
pkey indexes retain the historical behavior of not naming specific columns
at all.)
An example of the results:
regression=# create table foo (f1 int, f2 text,
regression(# exclude (f1 with =, lower(f2) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo"
CREATE TABLE
regression=# \d foo_f1_lower_exclusion
Index "public.foo_f1_lower_exclusion"
Column | Type | Definition
--------+---------+------------
f1 | integer | f1
lower | text | lower(f2)
btree, for table "public.foo"
2009-12-23 03:35:25 +01:00
|
|
|
* indexColNames: column names to use for index (List of char *)
|
2006-05-11 01:18:39 +02:00
|
|
|
* accessMethodObjectId: OID of index AM to use
|
|
|
|
* tableSpaceId: OID of tablespace to use
|
2011-04-22 23:43:18 +02:00
|
|
|
* collationObjectId: array of collation OIDs, one per index column
|
2006-05-11 01:18:39 +02:00
|
|
|
* classObjectId: array of index opclass OIDs, one per index column
|
2007-01-09 03:14:16 +01:00
|
|
|
* coloptions: array of per-index-column indoption settings
|
2006-07-04 00:45:41 +02:00
|
|
|
* reloptions: AM-specific options
|
2017-11-14 15:19:05 +01:00
|
|
|
* flags: bitmask that can include any combination of these bits:
|
|
|
|
* INDEX_CREATE_IS_PRIMARY
|
|
|
|
* the index is a primary key
|
|
|
|
* INDEX_CREATE_ADD_CONSTRAINT:
|
|
|
|
* invoke index_constraint_create also
|
|
|
|
* INDEX_CREATE_SKIP_BUILD:
|
|
|
|
* skip the index_build() step for the moment; caller must do it
|
|
|
|
* later (typically via reindex_index())
|
|
|
|
* INDEX_CREATE_CONCURRENT:
|
|
|
|
* do not lock the table against writers. The index will be
|
|
|
|
* marked "invalid" and the caller must take additional steps
|
|
|
|
* to fix it up.
|
|
|
|
* INDEX_CREATE_IF_NOT_EXISTS:
|
|
|
|
* do not throw an error if a relation with the same name
|
|
|
|
* already exists.
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
* INDEX_CREATE_PARTITIONED:
|
|
|
|
* create a partitioned index (table must be partitioned)
|
2017-11-14 15:19:05 +01:00
|
|
|
* constr_flags: flags passed to index_constraint_create
|
|
|
|
* (only if INDEX_CREATE_ADD_CONSTRAINT is set)
|
2006-05-11 01:18:39 +02:00
|
|
|
* allow_system_table_mods: allow table to be a system catalog
|
2012-12-06 03:09:46 +01:00
|
|
|
* is_internal: if true, post creation hook for new index
|
2005-04-14 03:38:22 +02:00
|
|
|
*
|
2009-12-07 06:22:23 +01:00
|
|
|
* Returns the OID of the created index.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2001-08-10 20:57:42 +02:00
|
|
|
Oid
|
2011-01-25 21:42:03 +01:00
|
|
|
index_create(Relation heapRelation,
|
2002-03-31 08:26:32 +02:00
|
|
|
const char *indexRelationName,
|
2005-04-14 03:38:22 +02:00
|
|
|
Oid indexRelationId,
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
Oid parentIndexRelid,
|
2011-07-18 17:02:48 +02:00
|
|
|
Oid relFileNode,
|
2000-07-15 00:18:02 +02:00
|
|
|
IndexInfo *indexInfo,
|
Adjust naming of indexes and their columns per recent discussion.
Index expression columns are now named after the FigureColname result for
their expressions, rather than always being "pg_expression_N". Digits are
appended to this name if needed to make the column name unique within the
index. (That happens for regular columns too, thus fixing the old problem
that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes
there was no real reason to do such a thing, but now maybe there is.)
Default names for indexes and associated constraints now include the column
names of all their columns, not only the first one as in previous practice.
(Of course, this will be truncated as needed to fit in NAMEDATALEN. Also,
pkey indexes retain the historical behavior of not naming specific columns
at all.)
An example of the results:
regression=# create table foo (f1 int, f2 text,
regression(# exclude (f1 with =, lower(f2) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo"
CREATE TABLE
regression=# \d foo_f1_lower_exclusion
Index "public.foo_f1_lower_exclusion"
Column | Type | Definition
--------+---------+------------
f1 | integer | f1
lower | text | lower(f2)
btree, for table "public.foo"
2009-12-23 03:35:25 +01:00
|
|
|
List *indexColNames,
|
1997-09-07 07:04:48 +02:00
|
|
|
Oid accessMethodObjectId,
|
2004-06-18 08:14:31 +02:00
|
|
|
Oid tableSpaceId,
|
2011-02-08 22:04:18 +01:00
|
|
|
Oid *collationObjectId,
|
1998-09-01 05:29:17 +02:00
|
|
|
Oid *classObjectId,
|
2007-01-09 03:14:16 +01:00
|
|
|
int16 *coloptions,
|
2006-07-04 00:45:41 +02:00
|
|
|
Datum reloptions,
|
2017-11-14 15:19:05 +01:00
|
|
|
bits16 flags,
|
|
|
|
bits16 constr_flags,
|
2004-05-05 06:48:48 +02:00
|
|
|
bool allow_system_table_mods,
|
2017-11-14 15:19:05 +01:00
|
|
|
bool is_internal)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2011-01-25 21:42:03 +01:00
|
|
|
Oid heapRelationId = RelationGetRelid(heapRelation);
|
2005-08-12 03:36:05 +02:00
|
|
|
Relation pg_class;
|
1997-09-08 04:41:22 +02:00
|
|
|
Relation indexRelation;
|
|
|
|
TupleDesc indexTupDesc;
|
2002-04-27 23:24:34 +02:00
|
|
|
bool shared_relation;
|
2010-02-07 21:48:13 +01:00
|
|
|
bool mapped_relation;
|
2009-12-07 06:22:23 +01:00
|
|
|
bool is_exclusion;
|
2002-03-26 20:17:02 +01:00
|
|
|
Oid namespaceId;
|
2002-07-12 20:43:19 +02:00
|
|
|
int i;
|
2010-12-13 18:34:26 +01:00
|
|
|
char relpersistence;
|
2017-11-14 15:19:05 +01:00
|
|
|
bool isprimary = (flags & INDEX_CREATE_IS_PRIMARY) != 0;
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
bool invalid = (flags & INDEX_CREATE_INVALID) != 0;
|
2017-11-14 15:19:05 +01:00
|
|
|
bool concurrent = (flags & INDEX_CREATE_CONCURRENT) != 0;
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
bool partitioned = (flags & INDEX_CREATE_PARTITIONED) != 0;
|
|
|
|
char relkind;
|
2017-11-14 15:19:05 +01:00
|
|
|
|
|
|
|
/* constraint flags can only be set when a constraint is requested */
|
|
|
|
Assert((constr_flags == 0) ||
|
|
|
|
((flags & INDEX_CREATE_ADD_CONSTRAINT) != 0));
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
/* partitioned indexes must never be "built" by themselves */
|
|
|
|
Assert(!partitioned || (flags & INDEX_CREATE_SKIP_BUILD));
|
1999-05-25 18:15:34 +02:00
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
relkind = partitioned ? RELKIND_PARTITIONED_INDEX : RELKIND_INDEX;
|
2009-12-07 06:22:23 +01:00
|
|
|
is_exclusion = (indexInfo->ii_ExclusionOps != NULL);
|
|
|
|
|
2005-08-12 03:36:05 +02:00
|
|
|
pg_class = heap_open(RelationRelationId, RowExclusiveLock);
|
|
|
|
|
2002-04-27 23:24:34 +02:00
|
|
|
/*
|
2002-09-04 22:31:48 +02:00
|
|
|
* The index will be in the same namespace as its parent table, and is
|
2010-02-26 03:01:40 +01:00
|
|
|
* shared across databases if and only if the parent is. Likewise, it
|
2010-12-13 18:34:26 +01:00
|
|
|
* will use the relfilenode map if and only if the parent does; and it
|
|
|
|
* inherits the parent's relpersistence.
|
2002-04-27 23:24:34 +02:00
|
|
|
*/
|
2002-03-26 20:17:02 +01:00
|
|
|
namespaceId = RelationGetNamespace(heapRelation);
|
2002-04-27 23:24:34 +02:00
|
|
|
shared_relation = heapRelation->rd_rel->relisshared;
|
2010-02-07 21:48:13 +01:00
|
|
|
mapped_relation = RelationIsMapped(heapRelation);
|
2010-12-13 18:34:26 +01:00
|
|
|
relpersistence = heapRelation->rd_rel->relpersistence;
|
2002-03-26 20:17:02 +01:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* check parameters
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2003-05-28 18:04:02 +02:00
|
|
|
if (indexInfo->ii_NumIndexAttrs < 1)
|
2001-08-10 17:49:39 +02:00
|
|
|
elog(ERROR, "must index at least one column");
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2002-03-26 20:17:02 +01:00
|
|
|
if (!allow_system_table_mods &&
|
2002-04-12 22:38:31 +02:00
|
|
|
IsSystemRelation(heapRelation) &&
|
2002-03-26 20:17:02 +01:00
|
|
|
IsNormalProcessingMode())
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("user-defined indexes on system catalog tables are not supported")));
|
2001-04-02 16:34:25 +02:00
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* concurrent index build on a system catalog is unsafe because we tend to
|
|
|
|
* release locks before committing in catalogs
|
2006-08-25 06:06:58 +02:00
|
|
|
*/
|
|
|
|
if (concurrent &&
|
|
|
|
IsSystemRelation(heapRelation))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("concurrent index creation on system catalog tables is not supported")));
|
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* This case is currently not supported, but there's no way to ask for it
|
|
|
|
* in the grammar anyway, so it can't happen.
|
2009-12-07 06:22:23 +01:00
|
|
|
*/
|
|
|
|
if (concurrent && is_exclusion)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg_internal("concurrent index creation for exclusion constraints is not supported")));
|
|
|
|
|
2002-04-27 23:24:34 +02:00
|
|
|
/*
|
|
|
|
* We cannot allow indexing a shared relation after initdb (because
|
|
|
|
* there's no way to make the entry in other databases' pg_class).
|
|
|
|
*/
|
2006-07-31 22:09:10 +02:00
|
|
|
if (shared_relation && !IsBootstrapProcessingMode())
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("shared indexes cannot be created after initdb")));
|
2002-04-27 23:24:34 +02:00
|
|
|
|
2007-10-12 20:55:12 +02:00
|
|
|
/*
|
2010-02-07 21:48:13 +01:00
|
|
|
* Shared relations must be in pg_global, too (last-ditch check)
|
2007-10-12 20:55:12 +02:00
|
|
|
*/
|
2010-02-07 21:48:13 +01:00
|
|
|
if (shared_relation && tableSpaceId != GLOBALTABLESPACE_OID)
|
|
|
|
elog(ERROR, "shared relations must be placed in pg_global tablespace");
|
2007-10-12 20:55:12 +02:00
|
|
|
|
2002-03-31 08:26:32 +02:00
|
|
|
if (get_relname_relid(indexRelationName, namespaceId))
|
2014-11-06 10:48:33 +01:00
|
|
|
{
|
2017-11-14 15:19:05 +01:00
|
|
|
if ((flags & INDEX_CREATE_IF_NOT_EXISTS) != 0)
|
2014-11-06 10:48:33 +01:00
|
|
|
{
|
|
|
|
ereport(NOTICE,
|
|
|
|
(errcode(ERRCODE_DUPLICATE_TABLE),
|
|
|
|
errmsg("relation \"%s\" already exists, skipping",
|
|
|
|
indexRelationName)));
|
|
|
|
heap_close(pg_class, RowExclusiveLock);
|
|
|
|
return InvalidOid;
|
|
|
|
}
|
|
|
|
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DUPLICATE_TABLE),
|
|
|
|
errmsg("relation \"%s\" already exists",
|
|
|
|
indexRelationName)));
|
2014-11-06 10:48:33 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2001-08-22 20:24:26 +02:00
|
|
|
* construct tuple descriptor for index tuples
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2003-05-28 18:04:02 +02:00
|
|
|
indexTupDesc = ConstructTupleDescriptor(heapRelation,
|
|
|
|
indexInfo,
|
Adjust naming of indexes and their columns per recent discussion.
Index expression columns are now named after the FigureColname result for
their expressions, rather than always being "pg_expression_N". Digits are
appended to this name if needed to make the column name unique within the
index. (That happens for regular columns too, thus fixing the old problem
that CREATE INDEX fooi ON foo (f1, f1) fails. Before exclusion indexes
there was no real reason to do such a thing, but now maybe there is.)
Default names for indexes and associated constraints now include the column
names of all their columns, not only the first one as in previous practice.
(Of course, this will be truncated as needed to fit in NAMEDATALEN. Also,
pkey indexes retain the historical behavior of not naming specific columns
at all.)
An example of the results:
regression=# create table foo (f1 int, f2 text,
regression(# exclude (f1 with =, lower(f2) with =));
NOTICE: CREATE TABLE / EXCLUDE will create implicit index "foo_f1_lower_exclusion" for table "foo"
CREATE TABLE
regression=# \d foo_f1_lower_exclusion
Index "public.foo_f1_lower_exclusion"
Column | Type | Definition
--------+---------+------------
f1 | integer | f1
lower | text | lower(f2)
btree, for table "public.foo"
2009-12-23 03:35:25 +01:00
|
|
|
indexColNames,
|
2008-09-15 20:43:41 +02:00
|
|
|
accessMethodObjectId,
|
2011-02-08 22:04:18 +01:00
|
|
|
collationObjectId,
|
2003-05-28 18:04:02 +02:00
|
|
|
classObjectId);
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2010-02-03 02:14:17 +01:00
|
|
|
/*
|
|
|
|
* Allocate an OID for the index, unless we were told what to use.
|
|
|
|
*
|
|
|
|
* The OID will be the relfilenode as well, so make sure it doesn't
|
|
|
|
* collide with either pg_class OIDs or existing physical files.
|
|
|
|
*/
|
|
|
|
if (!OidIsValid(indexRelationId))
|
2010-01-06 04:04:03 +01:00
|
|
|
{
|
2014-08-26 04:19:05 +02:00
|
|
|
/* Use binary-upgrade override for pg_class.oid/relfilenode? */
|
|
|
|
if (IsBinaryUpgrade)
|
2010-02-03 02:14:17 +01:00
|
|
|
{
|
2014-08-26 04:19:05 +02:00
|
|
|
if (!OidIsValid(binary_upgrade_next_index_pg_class_oid))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("pg_class index OID value not set when in binary upgrade mode")));
|
|
|
|
|
2011-01-08 03:25:34 +01:00
|
|
|
indexRelationId = binary_upgrade_next_index_pg_class_oid;
|
|
|
|
binary_upgrade_next_index_pg_class_oid = InvalidOid;
|
2010-02-03 02:14:17 +01:00
|
|
|
}
|
|
|
|
else
|
2010-08-13 22:10:54 +02:00
|
|
|
{
|
|
|
|
indexRelationId =
|
2010-12-13 18:34:26 +01:00
|
|
|
GetNewRelFileNode(tableSpaceId, pg_class, relpersistence);
|
2010-08-13 22:10:54 +02:00
|
|
|
}
|
2010-01-06 04:04:03 +01:00
|
|
|
}
|
2005-08-12 03:36:05 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
* create the index relation's relcache entry and, if necessary, the
|
|
|
|
* physical disk file. (If we fail further down, it's the smgr's
|
|
|
|
* responsibility to remove the disk file again, if any.)
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2002-03-26 20:17:02 +01:00
|
|
|
indexRelation = heap_create(indexRelationName,
|
|
|
|
namespaceId,
|
2004-06-18 08:14:31 +02:00
|
|
|
tableSpaceId,
|
2005-04-14 03:38:22 +02:00
|
|
|
indexRelationId,
|
2011-07-18 17:02:48 +02:00
|
|
|
relFileNode,
|
2002-03-26 20:17:02 +01:00
|
|
|
indexTupDesc,
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
relkind,
|
2010-12-13 18:34:26 +01:00
|
|
|
relpersistence,
|
2002-04-27 23:24:34 +02:00
|
|
|
shared_relation,
|
2013-06-03 16:22:31 +02:00
|
|
|
mapped_relation,
|
|
|
|
allow_system_table_mods);
|
2002-08-11 23:17:35 +02:00
|
|
|
|
2005-08-12 03:36:05 +02:00
|
|
|
Assert(indexRelationId == RelationGetRelid(indexRelation));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-11-08 23:10:03 +01:00
|
|
|
/*
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
* Obtain exclusive lock on it. Although no other transactions can see it
|
2000-11-08 23:10:03 +01:00
|
|
|
* until we commit, this prevents deadlock-risk complaints from lock
|
|
|
|
* manager in cases such as CLUSTER.
|
|
|
|
*/
|
|
|
|
LockRelation(indexRelation, AccessExclusiveLock);
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Fill in fields of the index's pg_class entry that are not set correctly
|
|
|
|
* by heap_create.
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
2002-04-27 23:24:34 +02:00
|
|
|
* XXX should have a cleaner way to create cataloged indexes
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2005-08-26 05:08:15 +02:00
|
|
|
indexRelation->rd_rel->relowner = heapRelation->rd_rel->relowner;
|
2002-04-27 23:24:34 +02:00
|
|
|
indexRelation->rd_rel->relam = accessMethodObjectId;
|
2002-09-02 03:05:06 +02:00
|
|
|
indexRelation->rd_rel->relhasoids = false;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-04-27 23:24:34 +02:00
|
|
|
/*
|
|
|
|
* store index's pg_class entry
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2006-07-04 00:45:41 +02:00
|
|
|
InsertPgClassTuple(pg_class, indexRelation,
|
|
|
|
RelationGetRelid(indexRelation),
|
2009-10-05 21:24:49 +02:00
|
|
|
(Datum) 0,
|
2006-07-04 00:45:41 +02:00
|
|
|
reloptions);
|
2005-08-12 03:36:05 +02:00
|
|
|
|
|
|
|
/* done with pg_class */
|
|
|
|
heap_close(pg_class, RowExclusiveLock);
|
1996-08-26 08:32:06 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* now update the object id's of all the attribute tuple forms in the
|
|
|
|
* index relation's tuple descriptor
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-07-15 00:18:02 +02:00
|
|
|
InitializeAttributeOids(indexRelation,
|
|
|
|
indexInfo->ii_NumIndexAttrs,
|
2005-08-12 03:36:05 +02:00
|
|
|
indexRelationId);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* append ATTRIBUTE tuples for the index
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-15 00:18:02 +02:00
|
|
|
AppendAttributeTuples(indexRelation, indexInfo->ii_NumIndexAttrs);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* update pg_index
|
|
|
|
* (append INDEX tuple)
|
|
|
|
*
|
|
|
|
* Note that this stows away a representation of "predicate".
|
|
|
|
* (Or, could define a rule to maintain the predicate) --Nels, Feb '92
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
UpdateIndexRelation(indexRelationId, heapRelationId, parentIndexRelid,
|
|
|
|
indexInfo,
|
2011-04-22 23:43:18 +02:00
|
|
|
collationObjectId, classObjectId, coloptions,
|
|
|
|
isprimary, is_exclusion,
|
2017-11-14 15:19:05 +01:00
|
|
|
(constr_flags & INDEX_CONSTR_CREATE_DEFERRABLE) == 0,
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
!concurrent && !invalid,
|
2009-07-29 22:56:21 +02:00
|
|
|
!concurrent);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
/* update pg_inherits, if needed */
|
|
|
|
if (OidIsValid(parentIndexRelid))
|
|
|
|
StoreSingleInheritance(indexRelationId, parentIndexRelid, 1);
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2002-07-12 20:43:19 +02:00
|
|
|
* Register constraint and dependencies for the index.
|
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* If the index is from a CONSTRAINT clause, construct a pg_constraint
|
2011-01-25 21:42:03 +01:00
|
|
|
* entry. The index will be linked to the constraint, which in turn is
|
|
|
|
* linked to the table. If it's not a CONSTRAINT, we need to make a
|
|
|
|
* dependency directly on the table.
|
2002-07-12 20:43:19 +02:00
|
|
|
*
|
2002-09-04 22:31:48 +02:00
|
|
|
* We don't need a dependency on the namespace, because there'll be an
|
|
|
|
* indirect dependency via our parent table.
|
2002-07-18 18:47:26 +02:00
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* During bootstrap we can't register any dependencies, and we don't try
|
|
|
|
* to make a constraint either.
|
2002-07-12 20:43:19 +02:00
|
|
|
*/
|
|
|
|
if (!IsBootstrapProcessingMode())
|
|
|
|
{
|
2002-09-04 22:31:48 +02:00
|
|
|
ObjectAddress myself,
|
|
|
|
referenced;
|
2002-07-12 20:43:19 +02:00
|
|
|
|
2005-04-14 03:38:22 +02:00
|
|
|
myself.classId = RelationRelationId;
|
2005-08-12 03:36:05 +02:00
|
|
|
myself.objectId = indexRelationId;
|
2002-07-12 20:43:19 +02:00
|
|
|
myself.objectSubId = 0;
|
|
|
|
|
2017-11-14 15:19:05 +01:00
|
|
|
if ((flags & INDEX_CREATE_ADD_CONSTRAINT) != 0)
|
2002-07-12 20:43:19 +02:00
|
|
|
{
|
|
|
|
char constraintType;
|
|
|
|
|
2006-05-11 01:18:39 +02:00
|
|
|
if (isprimary)
|
2002-07-12 20:43:19 +02:00
|
|
|
constraintType = CONSTRAINT_PRIMARY;
|
|
|
|
else if (indexInfo->ii_Unique)
|
|
|
|
constraintType = CONSTRAINT_UNIQUE;
|
2009-12-07 06:22:23 +01:00
|
|
|
else if (is_exclusion)
|
|
|
|
constraintType = CONSTRAINT_EXCLUSION;
|
2002-07-12 20:43:19 +02:00
|
|
|
else
|
|
|
|
{
|
2009-12-07 06:22:23 +01:00
|
|
|
elog(ERROR, "constraint must be PRIMARY, UNIQUE or EXCLUDE");
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
constraintType = 0; /* keep compiler quiet */
|
2002-07-12 20:43:19 +02:00
|
|
|
}
|
|
|
|
|
2011-01-25 21:42:03 +01:00
|
|
|
index_constraint_create(heapRelation,
|
|
|
|
indexRelationId,
|
|
|
|
indexInfo,
|
|
|
|
indexRelationName,
|
|
|
|
constraintType,
|
2017-11-14 15:19:05 +01:00
|
|
|
constr_flags,
|
2013-03-18 03:55:14 +01:00
|
|
|
allow_system_table_mods,
|
|
|
|
is_internal);
|
2002-07-12 20:43:19 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
bool have_simple_col = false;
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
DependencyType deptype;
|
|
|
|
|
|
|
|
deptype = OidIsValid(parentIndexRelid) ? DEPENDENCY_INTERNAL_AUTO : DEPENDENCY_AUTO;
|
2007-11-09 00:22:54 +01:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/* Create auto dependencies on simply-referenced columns */
|
|
|
|
for (i = 0; i < indexInfo->ii_NumIndexAttrs; i++)
|
2002-07-12 20:43:19 +02:00
|
|
|
{
|
2003-05-28 18:04:02 +02:00
|
|
|
if (indexInfo->ii_KeyAttrNumbers[i] != 0)
|
|
|
|
{
|
2005-04-14 03:38:22 +02:00
|
|
|
referenced.classId = RelationRelationId;
|
2003-05-28 18:04:02 +02:00
|
|
|
referenced.objectId = heapRelationId;
|
|
|
|
referenced.objectSubId = indexInfo->ii_KeyAttrNumbers[i];
|
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
recordDependencyOn(&myself, &referenced, deptype);
|
2007-11-09 00:22:54 +01:00
|
|
|
|
|
|
|
have_simple_col = true;
|
2003-05-28 18:04:02 +02:00
|
|
|
}
|
2002-07-12 20:43:19 +02:00
|
|
|
}
|
2007-11-09 00:22:54 +01:00
|
|
|
|
|
|
|
/*
|
2010-11-02 22:15:07 +01:00
|
|
|
* If there are no simply-referenced columns, give the index an
|
2014-05-06 18:12:18 +02:00
|
|
|
* auto dependency on the whole table. In most cases, this will
|
2010-11-02 22:15:07 +01:00
|
|
|
* be redundant, but it might not be if the index expressions and
|
|
|
|
* predicate contain no Vars or only whole-row Vars.
|
2007-11-09 00:22:54 +01:00
|
|
|
*/
|
2010-11-02 22:15:07 +01:00
|
|
|
if (!have_simple_col)
|
2007-11-09 00:22:54 +01:00
|
|
|
{
|
|
|
|
referenced.classId = RelationRelationId;
|
|
|
|
referenced.objectId = heapRelationId;
|
|
|
|
referenced.objectSubId = 0;
|
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
recordDependencyOn(&myself, &referenced, deptype);
|
2007-11-09 00:22:54 +01:00
|
|
|
}
|
2002-07-12 20:43:19 +02:00
|
|
|
}
|
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
/* Store dependency on parent index, if any */
|
|
|
|
if (OidIsValid(parentIndexRelid))
|
|
|
|
{
|
|
|
|
referenced.classId = RelationRelationId;
|
|
|
|
referenced.objectId = parentIndexRelid;
|
|
|
|
referenced.objectSubId = 0;
|
|
|
|
|
|
|
|
recordDependencyOn(&myself, &referenced, DEPENDENCY_INTERNAL_AUTO);
|
|
|
|
}
|
|
|
|
|
2011-02-12 14:54:13 +01:00
|
|
|
/* Store dependency on collations */
|
2011-04-22 23:43:18 +02:00
|
|
|
/* The default collation is pinned, so don't bother recording it */
|
2011-02-12 14:54:13 +01:00
|
|
|
for (i = 0; i < indexInfo->ii_NumIndexAttrs; i++)
|
|
|
|
{
|
2011-04-22 23:43:18 +02:00
|
|
|
if (OidIsValid(collationObjectId[i]) &&
|
|
|
|
collationObjectId[i] != DEFAULT_COLLATION_OID)
|
2011-02-12 14:54:13 +01:00
|
|
|
{
|
|
|
|
referenced.classId = CollationRelationId;
|
|
|
|
referenced.objectId = collationObjectId[i];
|
|
|
|
referenced.objectSubId = 0;
|
|
|
|
|
|
|
|
recordDependencyOn(&myself, &referenced, DEPENDENCY_NORMAL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2002-07-30 00:14:11 +02:00
|
|
|
/* Store dependency on operator classes */
|
2016-04-08 20:52:13 +02:00
|
|
|
for (i = 0; i < indexInfo->ii_NumIndexAttrs; i++)
|
2002-07-30 00:14:11 +02:00
|
|
|
{
|
2005-04-14 22:03:27 +02:00
|
|
|
referenced.classId = OperatorClassRelationId;
|
2002-07-30 00:14:11 +02:00
|
|
|
referenced.objectId = classObjectId[i];
|
|
|
|
referenced.objectSubId = 0;
|
|
|
|
|
|
|
|
recordDependencyOn(&myself, &referenced, DEPENDENCY_NORMAL);
|
|
|
|
}
|
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/* Store dependencies on anything mentioned in index expressions */
|
|
|
|
if (indexInfo->ii_Expressions)
|
2002-07-12 20:43:19 +02:00
|
|
|
{
|
2003-05-28 18:04:02 +02:00
|
|
|
recordDependencyOnSingleRelExpr(&myself,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
(Node *) indexInfo->ii_Expressions,
|
2003-05-28 18:04:02 +02:00
|
|
|
heapRelationId,
|
|
|
|
DEPENDENCY_NORMAL,
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
DEPENDENCY_AUTO, false);
|
2003-05-28 18:04:02 +02:00
|
|
|
}
|
2002-07-12 20:43:19 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/* Store dependencies on anything mentioned in predicate */
|
|
|
|
if (indexInfo->ii_Predicate)
|
|
|
|
{
|
|
|
|
recordDependencyOnSingleRelExpr(&myself,
|
2005-10-15 04:49:52 +02:00
|
|
|
(Node *) indexInfo->ii_Predicate,
|
2003-05-28 18:04:02 +02:00
|
|
|
heapRelationId,
|
|
|
|
DEPENDENCY_NORMAL,
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
DEPENDENCY_AUTO, false);
|
2002-07-12 20:43:19 +02:00
|
|
|
}
|
|
|
|
}
|
2009-07-29 22:56:21 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Bootstrap mode - assert we weren't asked for constraint support */
|
2017-11-14 15:19:05 +01:00
|
|
|
Assert((flags & INDEX_CREATE_ADD_CONSTRAINT) == 0);
|
2009-07-29 22:56:21 +02:00
|
|
|
}
|
2002-07-12 20:43:19 +02:00
|
|
|
|
2012-10-23 23:07:26 +02:00
|
|
|
/* Post creation hook for new index */
|
2013-03-07 02:52:06 +01:00
|
|
|
InvokeObjectPostCreateHookArg(RelationRelationId,
|
|
|
|
indexRelationId, 0, is_internal);
|
2012-10-23 23:07:26 +02:00
|
|
|
|
2002-07-12 20:43:19 +02:00
|
|
|
/*
|
2005-06-25 18:53:49 +02:00
|
|
|
* Advance the command counter so that we can see the newly-entered
|
|
|
|
* catalog tuples for the index.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2001-10-07 01:21:45 +02:00
|
|
|
CommandCounterIncrement();
|
|
|
|
|
2005-06-25 18:53:49 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* In bootstrap mode, we have to fill in the index strategy structure with
|
|
|
|
* information from the catalogs. If we aren't bootstrapping, then the
|
|
|
|
* relcache entry has already been rebuilt thanks to sinval update during
|
|
|
|
* CommandCounterIncrement.
|
2005-06-25 18:53:49 +02:00
|
|
|
*/
|
|
|
|
if (IsBootstrapProcessingMode())
|
|
|
|
RelationInitIndexAccessInfo(indexRelation);
|
|
|
|
else
|
|
|
|
Assert(indexRelation->rd_indexcxt != NULL);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* If this is bootstrap (initdb) time, then we don't actually fill in the
|
|
|
|
* index yet. We'll be creating more indexes and classes later, so we
|
|
|
|
* delay filling them in until just before we're done with bootstrapping.
|
2017-11-14 15:19:05 +01:00
|
|
|
* Similarly, if the caller specified to skip the build then filling the
|
|
|
|
* index is delayed till later (ALTER TABLE can save work in some cases
|
|
|
|
* with this). Otherwise, we call the AM routine that constructs the
|
|
|
|
* index.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
|
|
|
if (IsBootstrapProcessingMode())
|
1997-03-19 08:44:45 +01:00
|
|
|
{
|
2005-08-12 03:36:05 +02:00
|
|
|
index_register(heapRelationId, indexRelationId, indexInfo);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2017-11-14 15:19:05 +01:00
|
|
|
else if ((flags & INDEX_CREATE_SKIP_BUILD) != 0)
|
2004-05-05 06:48:48 +02:00
|
|
|
{
|
2006-05-11 01:18:39 +02:00
|
|
|
/*
|
|
|
|
* Caller is responsible for filling the index later on. However,
|
2006-10-04 02:30:14 +02:00
|
|
|
* we'd better make sure that the heap relation is correctly marked as
|
|
|
|
* having an index.
|
2006-05-11 01:18:39 +02:00
|
|
|
*/
|
|
|
|
index_update_stats(heapRelation,
|
|
|
|
true,
|
|
|
|
isprimary,
|
2011-10-14 23:23:01 +02:00
|
|
|
-1.0);
|
2006-05-11 01:18:39 +02:00
|
|
|
/* Make the above update visible */
|
|
|
|
CommandCounterIncrement();
|
2004-05-05 06:48:48 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
2004-05-05 06:48:48 +02:00
|
|
|
{
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
index_build(heapRelation, indexRelation, indexInfo, isprimary, false,
|
|
|
|
true);
|
2004-05-05 06:48:48 +02:00
|
|
|
}
|
2001-08-10 20:57:42 +02:00
|
|
|
|
2006-05-11 01:18:39 +02:00
|
|
|
/*
|
2011-01-25 21:42:03 +01:00
|
|
|
* Close the index; but we keep the lock that we acquired above until end
|
2014-05-06 18:12:18 +02:00
|
|
|
* of transaction. Closing the heap is caller's responsibility.
|
2006-05-11 01:18:39 +02:00
|
|
|
*/
|
2006-07-31 22:09:10 +02:00
|
|
|
index_close(indexRelation, NoLock);
|
2006-05-11 01:18:39 +02:00
|
|
|
|
2005-08-12 03:36:05 +02:00
|
|
|
return indexRelationId;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2011-01-25 21:42:03 +01:00
|
|
|
/*
|
|
|
|
* index_constraint_create
|
|
|
|
*
|
2015-03-25 21:17:56 +01:00
|
|
|
* Set up a constraint associated with an index. Return the new constraint's
|
|
|
|
* address.
|
2011-01-25 21:42:03 +01:00
|
|
|
*
|
|
|
|
* heapRelation: table owning the index (must be suitably locked by caller)
|
|
|
|
* indexRelationId: OID of the index
|
|
|
|
* indexInfo: same info executor uses to insert into the index
|
|
|
|
* constraintName: what it say (generally, should match name of index)
|
|
|
|
* constraintType: one of CONSTRAINT_PRIMARY, CONSTRAINT_UNIQUE, or
|
|
|
|
* CONSTRAINT_EXCLUSION
|
2017-11-14 15:19:05 +01:00
|
|
|
* flags: bitmask that can include any combination of these bits:
|
|
|
|
* INDEX_CONSTR_CREATE_MARK_AS_PRIMARY: index is a PRIMARY KEY
|
|
|
|
* INDEX_CONSTR_CREATE_DEFERRABLE: constraint is DEFERRABLE
|
|
|
|
* INDEX_CONSTR_CREATE_INIT_DEFERRED: constraint is INITIALLY DEFERRED
|
|
|
|
* INDEX_CONSTR_CREATE_UPDATE_INDEX: update the pg_index row
|
|
|
|
* INDEX_CONSTR_CREATE_REMOVE_OLD_DEPS: remove existing dependencies
|
|
|
|
* of index on table's columns
|
2011-01-25 21:42:03 +01:00
|
|
|
* allow_system_table_mods: allow table to be a system catalog
|
2013-03-18 03:55:14 +01:00
|
|
|
* is_internal: index is constructed due to internal process
|
2011-01-25 21:42:03 +01:00
|
|
|
*/
|
2015-03-25 21:17:56 +01:00
|
|
|
ObjectAddress
|
2011-01-25 21:42:03 +01:00
|
|
|
index_constraint_create(Relation heapRelation,
|
|
|
|
Oid indexRelationId,
|
|
|
|
IndexInfo *indexInfo,
|
|
|
|
const char *constraintName,
|
|
|
|
char constraintType,
|
2017-11-14 15:19:05 +01:00
|
|
|
bits16 constr_flags,
|
2013-03-18 03:55:14 +01:00
|
|
|
bool allow_system_table_mods,
|
|
|
|
bool is_internal)
|
2011-01-25 21:42:03 +01:00
|
|
|
{
|
|
|
|
Oid namespaceId = RelationGetNamespace(heapRelation);
|
|
|
|
ObjectAddress myself,
|
|
|
|
referenced;
|
|
|
|
Oid conOid;
|
2017-11-14 15:19:05 +01:00
|
|
|
bool deferrable;
|
|
|
|
bool initdeferred;
|
|
|
|
bool mark_as_primary;
|
|
|
|
|
|
|
|
deferrable = (constr_flags & INDEX_CONSTR_CREATE_DEFERRABLE) != 0;
|
|
|
|
initdeferred = (constr_flags & INDEX_CONSTR_CREATE_INIT_DEFERRED) != 0;
|
|
|
|
mark_as_primary = (constr_flags & INDEX_CONSTR_CREATE_MARK_AS_PRIMARY) != 0;
|
2011-01-25 21:42:03 +01:00
|
|
|
|
|
|
|
/* constraint creation support doesn't work while bootstrapping */
|
|
|
|
Assert(!IsBootstrapProcessingMode());
|
|
|
|
|
|
|
|
/* enforce system-table restriction */
|
|
|
|
if (!allow_system_table_mods &&
|
|
|
|
IsSystemRelation(heapRelation) &&
|
|
|
|
IsNormalProcessingMode())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("user-defined indexes on system catalog tables are not supported")));
|
|
|
|
|
|
|
|
/* primary/unique constraints shouldn't have any expressions */
|
|
|
|
if (indexInfo->ii_Expressions &&
|
|
|
|
constraintType != CONSTRAINT_EXCLUSION)
|
|
|
|
elog(ERROR, "constraints cannot have index expressions");
|
|
|
|
|
2012-08-11 18:51:24 +02:00
|
|
|
/*
|
|
|
|
* If we're manufacturing a constraint for a pre-existing index, we need
|
|
|
|
* to get rid of the existing auto dependencies for the index (the ones
|
|
|
|
* that index_create() would have made instead of calling this function).
|
|
|
|
*
|
|
|
|
* Note: this code would not necessarily do the right thing if the index
|
|
|
|
* has any expressions or predicate, but we'd never be turning such an
|
|
|
|
* index into a UNIQUE or PRIMARY KEY constraint.
|
|
|
|
*/
|
2017-11-14 15:19:05 +01:00
|
|
|
if (constr_flags & INDEX_CONSTR_CREATE_REMOVE_OLD_DEPS)
|
2012-08-11 18:51:24 +02:00
|
|
|
deleteDependencyRecordsForClass(RelationRelationId, indexRelationId,
|
|
|
|
RelationRelationId, DEPENDENCY_AUTO);
|
|
|
|
|
2011-01-25 21:42:03 +01:00
|
|
|
/*
|
|
|
|
* Construct a pg_constraint entry.
|
|
|
|
*/
|
|
|
|
conOid = CreateConstraintEntry(constraintName,
|
|
|
|
namespaceId,
|
|
|
|
constraintType,
|
|
|
|
deferrable,
|
|
|
|
initdeferred,
|
2011-02-08 13:23:20 +01:00
|
|
|
true,
|
2011-01-25 21:42:03 +01:00
|
|
|
RelationGetRelid(heapRelation),
|
|
|
|
indexInfo->ii_KeyAttrNumbers,
|
|
|
|
indexInfo->ii_NumIndexAttrs,
|
|
|
|
InvalidOid, /* no domain */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
indexRelationId, /* index OID */
|
2011-01-25 21:42:03 +01:00
|
|
|
InvalidOid, /* no foreign key */
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
0,
|
|
|
|
' ',
|
|
|
|
' ',
|
|
|
|
' ',
|
|
|
|
indexInfo->ii_ExclusionOps,
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
NULL, /* no check constraint */
|
2011-01-25 21:42:03 +01:00
|
|
|
NULL,
|
|
|
|
NULL,
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
true, /* islocal */
|
2012-06-10 21:20:04 +02:00
|
|
|
0, /* inhcount */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
true, /* noinherit */
|
2013-03-18 03:55:14 +01:00
|
|
|
is_internal);
|
2011-01-25 21:42:03 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Register the index as internally dependent on the constraint.
|
|
|
|
*
|
2012-08-11 18:51:24 +02:00
|
|
|
* Note that the constraint has a dependency on the table, so we don't
|
|
|
|
* need (or want) any direct dependency from the index to the table.
|
2011-01-25 21:42:03 +01:00
|
|
|
*/
|
|
|
|
myself.classId = RelationRelationId;
|
|
|
|
myself.objectId = indexRelationId;
|
|
|
|
myself.objectSubId = 0;
|
|
|
|
|
|
|
|
referenced.classId = ConstraintRelationId;
|
|
|
|
referenced.objectId = conOid;
|
|
|
|
referenced.objectSubId = 0;
|
|
|
|
|
|
|
|
recordDependencyOn(&myself, &referenced, DEPENDENCY_INTERNAL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the constraint is deferrable, create the deferred uniqueness
|
2011-04-10 17:42:00 +02:00
|
|
|
* checking trigger. (The trigger will be given an internal dependency on
|
|
|
|
* the constraint by CreateTrigger.)
|
2011-01-25 21:42:03 +01:00
|
|
|
*/
|
|
|
|
if (deferrable)
|
|
|
|
{
|
|
|
|
CreateTrigStmt *trigger;
|
|
|
|
|
|
|
|
trigger = makeNode(CreateTrigStmt);
|
|
|
|
trigger->trigname = (constraintType == CONSTRAINT_PRIMARY) ?
|
|
|
|
"PK_ConstraintTrigger" :
|
|
|
|
"Unique_ConstraintTrigger";
|
Avoid repeated name lookups during table and index DDL.
If the name lookups come to different conclusions due to concurrent
activity, we might perform some parts of the DDL on a different table
than other parts. At least in the case of CREATE INDEX, this can be
used to cause the permissions checks to be performed against a
different table than the index creation, allowing for a privilege
escalation attack.
This changes the calling convention for DefineIndex, CreateTrigger,
transformIndexStmt, transformAlterTableStmt, CheckIndexCompatible
(in 9.2 and newer), and AlterTable (in 9.1 and older). In addition,
CheckRelationOwnership is removed in 9.2 and newer and the calling
convention is changed in older branches. A field has also been added
to the Constraint node (FkConstraint in 8.4). Third-party code calling
these functions or using the Constraint node will require updating.
Report by Andres Freund. Patch by Robert Haas and Andres Freund,
reviewed by Tom Lane.
Security: CVE-2014-0062
2014-02-17 15:33:31 +01:00
|
|
|
trigger->relation = NULL;
|
2011-01-25 21:42:03 +01:00
|
|
|
trigger->funcname = SystemFuncName("unique_key_recheck");
|
|
|
|
trigger->args = NIL;
|
|
|
|
trigger->row = true;
|
|
|
|
trigger->timing = TRIGGER_TYPE_AFTER;
|
|
|
|
trigger->events = TRIGGER_TYPE_INSERT | TRIGGER_TYPE_UPDATE;
|
|
|
|
trigger->columns = NIL;
|
|
|
|
trigger->whenClause = NULL;
|
|
|
|
trigger->isconstraint = true;
|
|
|
|
trigger->deferrable = true;
|
|
|
|
trigger->initdeferred = initdeferred;
|
|
|
|
trigger->constrrel = NULL;
|
|
|
|
|
Avoid repeated name lookups during table and index DDL.
If the name lookups come to different conclusions due to concurrent
activity, we might perform some parts of the DDL on a different table
than other parts. At least in the case of CREATE INDEX, this can be
used to cause the permissions checks to be performed against a
different table than the index creation, allowing for a privilege
escalation attack.
This changes the calling convention for DefineIndex, CreateTrigger,
transformIndexStmt, transformAlterTableStmt, CheckIndexCompatible
(in 9.2 and newer), and AlterTable (in 9.1 and older). In addition,
CheckRelationOwnership is removed in 9.2 and newer and the calling
convention is changed in older branches. A field has also been added
to the Constraint node (FkConstraint in 8.4). Third-party code calling
these functions or using the Constraint node will require updating.
Report by Andres Freund. Patch by Robert Haas and Andres Freund,
reviewed by Tom Lane.
Security: CVE-2014-0062
2014-02-17 15:33:31 +01:00
|
|
|
(void) CreateTrigger(trigger, NULL, RelationGetRelid(heapRelation),
|
|
|
|
InvalidOid, conOid, indexRelationId, true);
|
2011-01-25 21:42:03 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If needed, mark the table as having a primary key. We assume it can't
|
|
|
|
* have been so marked already, so no need to clear the flag in the other
|
|
|
|
* case.
|
|
|
|
*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Note: this might better be done by callers. We do it here to avoid
|
2011-01-25 21:42:03 +01:00
|
|
|
* exposing index_update_stats() globally, but that wouldn't be necessary
|
|
|
|
* if relhaspkey went away.
|
|
|
|
*/
|
|
|
|
if (mark_as_primary)
|
|
|
|
index_update_stats(heapRelation,
|
|
|
|
true,
|
|
|
|
true,
|
2011-10-14 23:23:01 +02:00
|
|
|
-1.0);
|
2011-01-25 21:42:03 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If needed, mark the index as primary and/or deferred in pg_index.
|
|
|
|
*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Note: When making an existing index into a constraint, caller must have
|
|
|
|
* a table lock that prevents concurrent table updates; otherwise, there
|
|
|
|
* is a risk that concurrent readers of the table will miss seeing this
|
|
|
|
* index at all.
|
2011-01-25 21:42:03 +01:00
|
|
|
*/
|
2017-11-14 15:19:05 +01:00
|
|
|
if ((constr_flags & INDEX_CONSTR_CREATE_UPDATE_INDEX) &&
|
|
|
|
(mark_as_primary || deferrable))
|
2011-01-25 21:42:03 +01:00
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
Relation pg_index;
|
|
|
|
HeapTuple indexTuple;
|
|
|
|
Form_pg_index indexForm;
|
|
|
|
bool dirty = false;
|
2011-01-25 21:42:03 +01:00
|
|
|
|
|
|
|
pg_index = heap_open(IndexRelationId, RowExclusiveLock);
|
|
|
|
|
|
|
|
indexTuple = SearchSysCacheCopy1(INDEXRELID,
|
|
|
|
ObjectIdGetDatum(indexRelationId));
|
|
|
|
if (!HeapTupleIsValid(indexTuple))
|
|
|
|
elog(ERROR, "cache lookup failed for index %u", indexRelationId);
|
|
|
|
indexForm = (Form_pg_index) GETSTRUCT(indexTuple);
|
|
|
|
|
|
|
|
if (mark_as_primary && !indexForm->indisprimary)
|
|
|
|
{
|
|
|
|
indexForm->indisprimary = true;
|
|
|
|
dirty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (deferrable && indexForm->indimmediate)
|
|
|
|
{
|
|
|
|
indexForm->indimmediate = false;
|
|
|
|
dirty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dirty)
|
|
|
|
{
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(pg_index, &indexTuple->t_self, indexTuple);
|
2013-03-18 03:55:14 +01:00
|
|
|
|
|
|
|
InvokeObjectPostAlterHookArg(IndexRelationId, indexRelationId, 0,
|
|
|
|
InvalidOid, is_internal);
|
2011-01-25 21:42:03 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
heap_freetuple(indexTuple);
|
|
|
|
heap_close(pg_index, RowExclusiveLock);
|
|
|
|
}
|
2015-03-25 21:17:56 +01:00
|
|
|
|
|
|
|
return referenced;
|
2011-01-25 21:42:03 +01:00
|
|
|
}
|
|
|
|
|
2002-07-12 20:43:19 +02:00
|
|
|
/*
|
1999-12-10 04:56:14 +01:00
|
|
|
* index_drop
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
2002-07-12 20:43:19 +02:00
|
|
|
* NOTE: this routine should now only be called through performDeletion(),
|
|
|
|
* else associated dependencies won't be cleaned up.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
void
|
2012-04-06 11:21:40 +02:00
|
|
|
index_drop(Oid indexId, bool concurrent)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-06-17 23:49:04 +02:00
|
|
|
Oid heapId;
|
1999-11-21 21:01:10 +01:00
|
|
|
Relation userHeapRelation;
|
|
|
|
Relation userIndexRelation;
|
1997-09-08 04:41:22 +02:00
|
|
|
Relation indexRelation;
|
|
|
|
HeapTuple tuple;
|
2004-02-15 22:01:39 +01:00
|
|
|
bool hasexprs;
|
2012-04-06 11:21:40 +02:00
|
|
|
LockRelId heaprelid,
|
|
|
|
indexrelid;
|
2012-04-07 22:44:43 +02:00
|
|
|
LOCKTAG heaplocktag;
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
LOCKMODE lockmode;
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* To drop an index safely, we must grab exclusive lock on its parent
|
2009-05-31 22:55:37 +02:00
|
|
|
* table. Exclusive lock on the index alone is insufficient because
|
|
|
|
* another backend might be about to execute a query on the parent table.
|
|
|
|
* If it relies on a previously cached list of index OIDs, then it could
|
|
|
|
* attempt to access the just-dropped index. We must therefore take a
|
|
|
|
* table lock strong enough to prevent all queries on the table from
|
|
|
|
* proceeding until we commit and send out a shared-cache-inval notice
|
|
|
|
* that will make them update their index lists.
|
2012-10-18 19:58:30 +02:00
|
|
|
*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* In the concurrent case we avoid this requirement by disabling index use
|
|
|
|
* in multiple steps and waiting out any transactions that might be using
|
|
|
|
* the index, so we don't need exclusive lock on the parent table. Instead
|
|
|
|
* we take ShareUpdateExclusiveLock, to ensure that two sessions aren't
|
2014-05-06 18:12:18 +02:00
|
|
|
* doing CREATE/DROP INDEX CONCURRENTLY on the same index. (We will get
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* AccessExclusiveLock on the index below, once we're sure nobody else is
|
|
|
|
* using it.)
|
1999-09-18 21:08:25 +02:00
|
|
|
*/
|
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice:
look up the name, do permissions checks, and then lock the table; or
look up the name, lock the table, and then do permissions checks.
The first choice was wrong because the results of the name lookup
and permissions checks might be out-of-date by the time the table
lock was acquired, while the second allowed a user with no privileges
to interfere with access to a table by users who do have privileges
(e.g. if a malicious backend queues up for an AccessExclusiveLock on
a table on which AccessShareLock is already held, further attempts
to access the table will be blocked until the AccessExclusiveLock
is obtained and the malicious backend's transaction rolls back).
To fix, allow callers of RangeVarGetRelid() to pass a callback which
gets executed after performing the name lookup but before acquiring
the relation lock. If the name lookup is retried (because
invalidation messages are received), the callback will be re-executed
as well, so we get the best of both worlds. RangeVarGetRelid() is
renamed to RangeVarGetRelidExtended(); callers not wishing to supply
a callback can continue to invoke it as RangeVarGetRelid(), which is
now a macro. Since the only one caller that uses nowait = true now
passes a callback anyway, the RangeVarGetRelid() macro defaults nowait
as well. The callback can also be used for supplemental locking - for
example, REINDEX INDEX needs to acquire the table lock before the index
lock to reduce deadlock possibilities.
There's a lot more work to be done here to fix all the cases where this
can be a problem, but this commit provides the general infrastructure
and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE,
LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE.
Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
|
|
|
heapId = IndexGetRelation(indexId, false);
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
lockmode = concurrent ? ShareUpdateExclusiveLock : AccessExclusiveLock;
|
|
|
|
userHeapRelation = heap_open(heapId, lockmode);
|
|
|
|
userIndexRelation = index_open(indexId, lockmode);
|
1999-09-18 21:08:25 +02:00
|
|
|
|
2011-02-15 21:49:54 +01:00
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* We might still have open queries using it in our own session, which the
|
|
|
|
* above locking won't prevent, so test explicitly.
|
2011-02-15 21:49:54 +01:00
|
|
|
*/
|
|
|
|
CheckTableNotInUse(userIndexRelation, "DROP INDEX");
|
|
|
|
|
2012-04-06 11:21:40 +02:00
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* Drop Index Concurrently is more or less the reverse process of Create
|
|
|
|
* Index Concurrently.
|
2012-10-18 19:58:30 +02:00
|
|
|
*
|
|
|
|
* First we unset indisvalid so queries starting afterwards don't use the
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* index to answer queries anymore. We have to keep indisready = true so
|
|
|
|
* transactions that are still scanning the index can continue to see
|
|
|
|
* valid index contents. For instance, if they are using READ COMMITTED
|
|
|
|
* mode, and another transaction makes changes and commits, they need to
|
|
|
|
* see those new tuples in the index.
|
2012-10-18 19:58:30 +02:00
|
|
|
*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* After all transactions that could possibly have used the index for
|
|
|
|
* queries end, we can unset indisready and indislive, then wait till
|
|
|
|
* nobody could be touching it anymore. (Note: we need indislive because
|
|
|
|
* this state must be distinct from the initial state during CREATE INDEX
|
|
|
|
* CONCURRENTLY, which has indislive true while indisready and indisvalid
|
|
|
|
* are false. That's because in that state, transactions must examine the
|
|
|
|
* index for HOT-safety decisions, while in this state we don't want them
|
|
|
|
* to open it at all.)
|
|
|
|
*
|
|
|
|
* Since all predicate locks on the index are about to be made invalid, we
|
|
|
|
* must promote them to predicate locks on the heap. In the
|
|
|
|
* non-concurrent case we can just do that now. In the concurrent case
|
|
|
|
* it's a bit trickier. The predicate locks must be moved when there are
|
|
|
|
* no index scans in progress on the index and no more can subsequently
|
2014-05-06 18:12:18 +02:00
|
|
|
* start, so that no new predicate locks can be made on the index. Also,
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* they must be moved before heap inserts stop maintaining the index, else
|
|
|
|
* the conflict with the predicate lock on the index gap could be missed
|
|
|
|
* before the lock on the heap relation is in place to detect a conflict
|
|
|
|
* based on the heap tuple insert.
|
2012-04-06 11:21:40 +02:00
|
|
|
*/
|
|
|
|
if (concurrent)
|
|
|
|
{
|
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* We must commit our transaction in order to make the first pg_index
|
2014-05-06 18:12:18 +02:00
|
|
|
* state update visible to other sessions. If the DROP machinery has
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* already performed any other actions (removal of other objects,
|
|
|
|
* pg_depend entries, etc), the commit would make those actions
|
|
|
|
* permanent, which would leave us with inconsistent catalog state if
|
2014-05-06 18:12:18 +02:00
|
|
|
* we fail partway through the following sequence. Since DROP INDEX
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* CONCURRENTLY is restricted to dropping just one index that has no
|
|
|
|
* dependencies, we should get here before anything's been done ---
|
|
|
|
* but let's check that to be sure. We can verify that the current
|
|
|
|
* transaction has not executed any transactional updates by checking
|
|
|
|
* that no XID has been assigned.
|
2012-04-06 11:21:40 +02:00
|
|
|
*/
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
if (GetTopTransactionIdIfAny() != InvalidTransactionId)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("DROP INDEX CONCURRENTLY must be first action in transaction")));
|
2012-04-06 11:21:40 +02:00
|
|
|
|
2012-10-18 19:58:30 +02:00
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* Mark index invalid by updating its pg_index entry
|
2012-10-18 19:58:30 +02:00
|
|
|
*/
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
index_set_state_flags(indexId, INDEX_DROP_CLEAR_VALID);
|
2012-04-06 11:21:40 +02:00
|
|
|
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
/*
|
|
|
|
* Invalidate the relcache for the table, so that after this commit
|
|
|
|
* all sessions will refresh any cached plans that might reference the
|
|
|
|
* index.
|
|
|
|
*/
|
|
|
|
CacheInvalidateRelcache(userHeapRelation);
|
2012-04-06 11:21:40 +02:00
|
|
|
|
|
|
|
/* save lockrelid and locktag for below, then close but keep locks */
|
|
|
|
heaprelid = userHeapRelation->rd_lockInfo.lockRelId;
|
|
|
|
SET_LOCKTAG_RELATION(heaplocktag, heaprelid.dbId, heaprelid.relId);
|
|
|
|
indexrelid = userIndexRelation->rd_lockInfo.lockRelId;
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
|
|
|
|
heap_close(userHeapRelation, NoLock);
|
2012-04-06 11:21:40 +02:00
|
|
|
index_close(userIndexRelation, NoLock);
|
|
|
|
|
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* We must commit our current transaction so that the indisvalid
|
|
|
|
* update becomes visible to other transactions; then start another.
|
|
|
|
* Note that any previously-built data structures are lost in the
|
2014-05-06 18:12:18 +02:00
|
|
|
* commit. The only data we keep past here are the relation IDs.
|
2012-04-06 11:21:40 +02:00
|
|
|
*
|
|
|
|
* Before committing, get a session-level lock on the table, to ensure
|
|
|
|
* that neither it nor the index can be dropped before we finish. This
|
2012-06-10 21:20:04 +02:00
|
|
|
* cannot block, even if someone else is waiting for access, because
|
|
|
|
* we already have the same lock within our transaction.
|
2012-04-06 11:21:40 +02:00
|
|
|
*/
|
|
|
|
LockRelationIdForSession(&heaprelid, ShareUpdateExclusiveLock);
|
|
|
|
LockRelationIdForSession(&indexrelid, ShareUpdateExclusiveLock);
|
|
|
|
|
|
|
|
PopActiveSnapshot();
|
|
|
|
CommitTransactionCommand();
|
|
|
|
StartTransactionCommand();
|
|
|
|
|
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* Now we must wait until no running transaction could be using the
|
2014-01-03 17:22:03 +01:00
|
|
|
* index for a query. Use AccessExclusiveLock here to check for
|
2014-05-06 18:12:18 +02:00
|
|
|
* running transactions that hold locks of any kind on the table. Note
|
|
|
|
* we do not need to worry about xacts that open the table for reading
|
|
|
|
* after this point; they will see the index as invalid when they open
|
|
|
|
* the relation.
|
2012-04-06 11:21:40 +02:00
|
|
|
*
|
2012-06-10 21:20:04 +02:00
|
|
|
* Note: the reason we use actual lock acquisition here, rather than
|
|
|
|
* just checking the ProcArray and sleeping, is that deadlock is
|
|
|
|
* possible if one of the transactions in question is blocked trying
|
|
|
|
* to acquire an exclusive lock on our table. The lock code will
|
|
|
|
* detect deadlock and error out properly.
|
2012-04-06 11:21:40 +02:00
|
|
|
*/
|
2013-09-27 16:46:33 +02:00
|
|
|
WaitForLockers(heaplocktag, AccessExclusiveLock);
|
2012-04-06 11:21:40 +02:00
|
|
|
|
2012-10-21 23:35:42 +02:00
|
|
|
/*
|
|
|
|
* No more predicate locks will be acquired on this index, and we're
|
|
|
|
* about to stop doing inserts into the index which could show
|
|
|
|
* conflicts with existing predicate locks, so now is the time to move
|
|
|
|
* them to the heap relation.
|
|
|
|
*/
|
2012-11-07 20:23:39 +01:00
|
|
|
userHeapRelation = heap_open(heapId, ShareUpdateExclusiveLock);
|
|
|
|
userIndexRelation = index_open(indexId, ShareUpdateExclusiveLock);
|
2012-10-21 23:35:42 +02:00
|
|
|
TransferPredicateLocksToHeapRelation(userIndexRelation);
|
|
|
|
|
2012-10-18 19:58:30 +02:00
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* Now we are sure that nobody uses the index for queries; they just
|
2014-05-06 18:12:18 +02:00
|
|
|
* might have it open for updating it. So now we can unset indisready
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* and indislive, then wait till nobody could be using it at all
|
|
|
|
* anymore.
|
2012-10-18 19:58:30 +02:00
|
|
|
*/
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
index_set_state_flags(indexId, INDEX_DROP_SET_DEAD);
|
2012-10-18 19:58:30 +02:00
|
|
|
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
/*
|
|
|
|
* Invalidate the relcache for the table, so that after this commit
|
|
|
|
* all sessions will refresh the table's index list. Forgetting just
|
|
|
|
* the index's relcache entry is not enough.
|
|
|
|
*/
|
|
|
|
CacheInvalidateRelcache(userHeapRelation);
|
2012-10-18 19:58:30 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Close the relations again, though still holding session lock.
|
|
|
|
*/
|
|
|
|
heap_close(userHeapRelation, NoLock);
|
|
|
|
index_close(userIndexRelation, NoLock);
|
|
|
|
|
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* Again, commit the transaction to make the pg_index update visible
|
|
|
|
* to other sessions.
|
2012-10-18 19:58:30 +02:00
|
|
|
*/
|
|
|
|
CommitTransactionCommand();
|
|
|
|
StartTransactionCommand();
|
|
|
|
|
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* Wait till every transaction that saw the old index state has
|
2013-09-27 16:46:33 +02:00
|
|
|
* finished.
|
2012-10-18 19:58:30 +02:00
|
|
|
*/
|
2013-09-27 16:46:33 +02:00
|
|
|
WaitForLockers(heaplocktag, AccessExclusiveLock);
|
2012-10-18 19:58:30 +02:00
|
|
|
|
2012-04-06 11:21:40 +02:00
|
|
|
/*
|
|
|
|
* Re-open relations to allow us to complete our actions.
|
|
|
|
*
|
|
|
|
* At this point, nothing should be accessing the index, but lets
|
|
|
|
* leave nothing to chance and grab AccessExclusiveLock on the index
|
|
|
|
* before the physical deletion.
|
|
|
|
*/
|
|
|
|
userHeapRelation = heap_open(heapId, ShareUpdateExclusiveLock);
|
|
|
|
userIndexRelation = index_open(indexId, AccessExclusiveLock);
|
|
|
|
}
|
2012-10-21 23:35:42 +02:00
|
|
|
else
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
{
|
|
|
|
/* Not concurrent, so just transfer predicate locks and we're good */
|
2012-10-21 23:35:42 +02:00
|
|
|
TransferPredicateLocksToHeapRelation(userIndexRelation);
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
}
|
2011-06-08 12:47:21 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
* Schedule physical removal of the files (if any)
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
if (userIndexRelation->rd_rel->relkind != RELKIND_PARTITIONED_INDEX)
|
|
|
|
RelationDropStorage(userIndexRelation);
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Close and flush the index's relcache entry, to ensure relcache doesn't
|
|
|
|
* try to rebuild it while we're deleting catalog entries. We keep the
|
|
|
|
* lock though.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2006-07-31 22:09:10 +02:00
|
|
|
index_close(userIndexRelation, NoLock);
|
2004-08-28 23:05:26 +02:00
|
|
|
|
|
|
|
RelationForgetRelation(indexId);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2004-02-15 22:01:39 +01:00
|
|
|
* fix INDEX relation, and check for expressional index
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2005-04-14 22:03:27 +02:00
|
|
|
indexRelation = heap_open(IndexRelationId, RowExclusiveLock);
|
1999-09-18 21:08:25 +02:00
|
|
|
|
2010-02-14 19:42:19 +01:00
|
|
|
tuple = SearchSysCache1(INDEXRELID, ObjectIdGetDatum(indexId));
|
2000-11-16 23:30:52 +01:00
|
|
|
if (!HeapTupleIsValid(tuple))
|
2003-07-21 03:59:11 +02:00
|
|
|
elog(ERROR, "cache lookup failed for index %u", indexId);
|
1998-08-21 00:07:46 +02:00
|
|
|
|
2004-02-15 22:01:39 +01:00
|
|
|
hasexprs = !heap_attisnull(tuple, Anum_pg_index_indexprs);
|
|
|
|
|
2017-02-01 22:13:30 +01:00
|
|
|
CatalogTupleDelete(indexRelation, &tuple->t_self);
|
2002-07-14 23:08:08 +02:00
|
|
|
|
|
|
|
ReleaseSysCache(tuple);
|
1999-09-18 21:08:25 +02:00
|
|
|
heap_close(indexRelation, RowExclusiveLock);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2004-02-15 22:01:39 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* if it has any expression columns, we might have stored statistics about
|
|
|
|
* them.
|
2004-02-15 22:01:39 +01:00
|
|
|
*/
|
|
|
|
if (hasexprs)
|
2004-08-28 23:05:26 +02:00
|
|
|
RemoveStatistics(indexId, 0);
|
2004-02-15 22:01:39 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2004-08-28 23:05:26 +02:00
|
|
|
* fix ATTRIBUTE relation
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2004-08-28 23:05:26 +02:00
|
|
|
DeleteAttributeTuples(indexId);
|
1998-06-13 22:22:54 +02:00
|
|
|
|
2004-08-28 23:05:26 +02:00
|
|
|
/*
|
|
|
|
* fix RELATION relation
|
|
|
|
*/
|
|
|
|
DeleteRelationTuple(indexId);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
/*
|
|
|
|
* fix INHERITS relation
|
|
|
|
*/
|
|
|
|
DeleteInheritsTuple(indexId, InvalidOid);
|
|
|
|
|
2002-03-03 18:47:56 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* We are presently too lazy to attempt to compute the new correct value
|
|
|
|
* of relhasindex (the next VACUUM will fix it if necessary). So there is
|
|
|
|
* no need to update the pg_class tuple for the owning relation. But we
|
|
|
|
* must send out a shared-cache-inval notice on the owning relation to
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* ensure other backends update their relcache lists of indexes. (In the
|
|
|
|
* concurrent case, this is redundant but harmless.)
|
2002-03-03 18:47:56 +01:00
|
|
|
*/
|
2004-02-10 02:55:27 +01:00
|
|
|
CacheInvalidateRelcache(userHeapRelation);
|
2002-03-03 18:47:56 +01:00
|
|
|
|
1999-11-21 21:01:10 +01:00
|
|
|
/*
|
2004-08-28 23:05:26 +02:00
|
|
|
* Close owning rel, but keep lock
|
1999-11-21 21:01:10 +01:00
|
|
|
*/
|
|
|
|
heap_close(userHeapRelation, NoLock);
|
2012-04-06 11:21:40 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Release the session locks before we go.
|
|
|
|
*/
|
|
|
|
if (concurrent)
|
|
|
|
{
|
|
|
|
UnlockRelationIdForSession(&heaprelid, ShareUpdateExclusiveLock);
|
|
|
|
UnlockRelationIdForSession(&indexrelid, ShareUpdateExclusiveLock);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* index_build support
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
2000-07-15 00:18:02 +02:00
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
* BuildIndexInfo
|
2003-05-28 18:04:02 +02:00
|
|
|
* Construct an IndexInfo record for an open index
|
2000-07-15 00:18:02 +02:00
|
|
|
*
|
|
|
|
* IndexInfo stores the information about the index that's needed by
|
|
|
|
* FormIndexDatum, which is used for both index_build() and later insertion
|
2014-05-06 18:12:18 +02:00
|
|
|
* of individual index tuples. Normally we build an IndexInfo for an index
|
2000-07-15 00:18:02 +02:00
|
|
|
* just once per command, and then use it for (potentially) many tuples.
|
|
|
|
* ----------------
|
|
|
|
*/
|
2001-10-25 07:50:21 +02:00
|
|
|
IndexInfo *
|
2003-05-28 18:04:02 +02:00
|
|
|
BuildIndexInfo(Relation index)
|
2000-07-15 00:18:02 +02:00
|
|
|
{
|
|
|
|
IndexInfo *ii = makeNode(IndexInfo);
|
2003-05-28 18:04:02 +02:00
|
|
|
Form_pg_index indexStruct = index->rd_index;
|
2000-07-15 00:18:02 +02:00
|
|
|
int i;
|
2016-04-08 20:52:13 +02:00
|
|
|
int numKeys;
|
2000-07-15 00:18:02 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/* check the number of keys, and copy attr numbers into the IndexInfo */
|
2016-04-08 20:52:13 +02:00
|
|
|
numKeys = indexStruct->indnatts;
|
|
|
|
if (numKeys < 1 || numKeys > INDEX_MAX_KEYS)
|
2003-05-28 18:04:02 +02:00
|
|
|
elog(ERROR, "invalid indnatts %d for index %u",
|
2016-04-08 20:52:13 +02:00
|
|
|
numKeys, RelationGetRelid(index));
|
|
|
|
ii->ii_NumIndexAttrs = numKeys;
|
|
|
|
for (i = 0; i < numKeys; i++)
|
2005-03-29 02:17:27 +02:00
|
|
|
ii->ii_KeyAttrNumbers[i] = indexStruct->indkey.values[i];
|
2000-07-15 00:18:02 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/* fetch any expressions needed for expressional indexes */
|
|
|
|
ii->ii_Expressions = RelationGetIndexExpressions(index);
|
|
|
|
ii->ii_ExpressionsState = NIL;
|
2000-07-15 00:18:02 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/* fetch index predicate if any */
|
|
|
|
ii->ii_Predicate = RelationGetIndexPredicate(index);
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ii->ii_PredicateState = NULL;
|
2000-07-15 00:18:02 +02:00
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
/* fetch exclusion constraint info if any */
|
2011-01-25 23:51:59 +01:00
|
|
|
if (indexStruct->indisexclusion)
|
2009-12-07 06:22:23 +01:00
|
|
|
{
|
|
|
|
RelationGetExclusionInfo(index,
|
|
|
|
&ii->ii_ExclusionOps,
|
|
|
|
&ii->ii_ExclusionProcs,
|
|
|
|
&ii->ii_ExclusionStrats);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ii->ii_ExclusionOps = NULL;
|
|
|
|
ii->ii_ExclusionProcs = NULL;
|
|
|
|
ii->ii_ExclusionStrats = NULL;
|
|
|
|
}
|
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/* other info */
|
2000-07-15 00:18:02 +02:00
|
|
|
ii->ii_Unique = indexStruct->indisunique;
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
ii->ii_ReadyForInserts = IndexIsReady(indexStruct);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/* assume not doing speculative insertion for now */
|
|
|
|
ii->ii_UniqueOps = NULL;
|
|
|
|
ii->ii_UniqueProcs = NULL;
|
|
|
|
ii->ii_UniqueStrats = NULL;
|
2007-09-20 19:56:33 +02:00
|
|
|
|
|
|
|
/* initialize index-build state to default */
|
|
|
|
ii->ii_Concurrent = false;
|
|
|
|
ii->ii_BrokenHotChain = false;
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
ii->ii_ParallelWorkers = 0;
|
2000-07-15 00:18:02 +02:00
|
|
|
|
Allow index AMs to cache data across aminsert calls within a SQL command.
It's always been possible for index AMs to cache data across successive
amgettuple calls within a single SQL command: the IndexScanDesc.opaque
field is meant for precisely that. However, no comparable facility
exists for amortizing setup work across successive aminsert calls.
This patch adds such a feature and teaches GIN, GIST, and BRIN to use it
to amortize catalog lookups they'd previously been doing on every call.
(The other standard index AMs keep everything they need in the relcache,
so there's little to improve there.)
For GIN, the overall improvement in a statement that inserts many rows
can be as much as 10%, though it seems a bit less for the other two.
In addition, this makes a really significant difference in runtime
for CLOBBER_CACHE_ALWAYS tests, since in those builds the repeated
catalog lookups are vastly more expensive.
The reason this has been hard up to now is that the aminsert function is
not passed any useful place to cache per-statement data. What I chose to
do is to add suitable fields to struct IndexInfo and pass that to aminsert.
That's not widening the index AM API very much because IndexInfo is already
within the ken of ambuild; in fact, by passing the same info to aminsert
as to ambuild, this is really removing an inconsistency in the AM API.
Discussion: https://postgr.es/m/27568.1486508680@sss.pgh.pa.us
2017-02-09 17:52:12 +01:00
|
|
|
/* set up for possible use by index AM */
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
ii->ii_Am = index->rd_rel->relam;
|
Allow index AMs to cache data across aminsert calls within a SQL command.
It's always been possible for index AMs to cache data across successive
amgettuple calls within a single SQL command: the IndexScanDesc.opaque
field is meant for precisely that. However, no comparable facility
exists for amortizing setup work across successive aminsert calls.
This patch adds such a feature and teaches GIN, GIST, and BRIN to use it
to amortize catalog lookups they'd previously been doing on every call.
(The other standard index AMs keep everything they need in the relcache,
so there's little to improve there.)
For GIN, the overall improvement in a statement that inserts many rows
can be as much as 10%, though it seems a bit less for the other two.
In addition, this makes a really significant difference in runtime
for CLOBBER_CACHE_ALWAYS tests, since in those builds the repeated
catalog lookups are vastly more expensive.
The reason this has been hard up to now is that the aminsert function is
not passed any useful place to cache per-statement data. What I chose to
do is to add suitable fields to struct IndexInfo and pass that to aminsert.
That's not widening the index AM API very much because IndexInfo is already
within the ken of ambuild; in fact, by passing the same info to aminsert
as to ambuild, this is really removing an inconsistency in the AM API.
Discussion: https://postgr.es/m/27568.1486508680@sss.pgh.pa.us
2017-02-09 17:52:12 +01:00
|
|
|
ii->ii_AmCache = NULL;
|
|
|
|
ii->ii_Context = CurrentMemoryContext;
|
|
|
|
|
2000-07-15 00:18:02 +02:00
|
|
|
return ii;
|
|
|
|
}
|
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
/*
|
|
|
|
* CompareIndexInfo
|
|
|
|
* Return whether the properties of two indexes (in different tables)
|
|
|
|
* indicate that they have the "same" definitions.
|
|
|
|
*
|
|
|
|
* Note: passing collations and opfamilies separately is a kludge. Adding
|
|
|
|
* them to IndexInfo may result in better coding here and elsewhere.
|
|
|
|
*
|
|
|
|
* Use convert_tuples_by_name_map(index2, index1) to build the attmap.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
CompareIndexInfo(IndexInfo *info1, IndexInfo *info2,
|
|
|
|
Oid *collations1, Oid *collations2,
|
|
|
|
Oid *opfamilies1, Oid *opfamilies2,
|
|
|
|
AttrNumber *attmap, int maplen)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (info1->ii_Unique != info2->ii_Unique)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* indexes are only equivalent if they have the same access method */
|
|
|
|
if (info1->ii_Am != info2->ii_Am)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* and same number of attributes */
|
|
|
|
if (info1->ii_NumIndexAttrs != info2->ii_NumIndexAttrs)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* and columns match through the attribute map (actual attribute numbers
|
|
|
|
* might differ!) Note that this implies that index columns that are
|
|
|
|
* expressions appear in the same positions. We will next compare the
|
|
|
|
* expressions themselves.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < info1->ii_NumIndexAttrs; i++)
|
|
|
|
{
|
|
|
|
if (maplen < info2->ii_KeyAttrNumbers[i])
|
|
|
|
elog(ERROR, "incorrect attribute map");
|
|
|
|
|
2018-01-19 20:34:44 +01:00
|
|
|
/* ignore expressions at this stage */
|
|
|
|
if ((info1->ii_KeyAttrNumbers[i] != InvalidAttrNumber) &&
|
|
|
|
(attmap[info2->ii_KeyAttrNumbers[i] - 1] !=
|
|
|
|
info1->ii_KeyAttrNumbers[i]))
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (collations1[i] != collations2[i])
|
|
|
|
return false;
|
|
|
|
if (opfamilies1[i] != opfamilies2[i])
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For expression indexes: either both are expression indexes, or neither
|
|
|
|
* is; if they are, make sure the expressions match.
|
|
|
|
*/
|
|
|
|
if ((info1->ii_Expressions != NIL) != (info2->ii_Expressions != NIL))
|
|
|
|
return false;
|
|
|
|
if (info1->ii_Expressions != NIL)
|
|
|
|
{
|
|
|
|
bool found_whole_row;
|
|
|
|
Node *mapped;
|
|
|
|
|
|
|
|
mapped = map_variable_attnos((Node *) info2->ii_Expressions,
|
|
|
|
1, 0, attmap, maplen,
|
|
|
|
InvalidOid, &found_whole_row);
|
|
|
|
if (found_whole_row)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* we could throw an error here, but seems out of scope for this
|
|
|
|
* routine.
|
|
|
|
*/
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!equal(info1->ii_Expressions, mapped))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Partial index predicates must be identical, if they exist */
|
|
|
|
if ((info1->ii_Predicate == NULL) != (info2->ii_Predicate == NULL))
|
|
|
|
return false;
|
|
|
|
if (info1->ii_Predicate != NULL)
|
|
|
|
{
|
|
|
|
bool found_whole_row;
|
|
|
|
Node *mapped;
|
|
|
|
|
|
|
|
mapped = map_variable_attnos((Node *) info2->ii_Predicate,
|
|
|
|
1, 0, attmap, maplen,
|
|
|
|
InvalidOid, &found_whole_row);
|
|
|
|
if (found_whole_row)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* we could throw an error here, but seems out of scope for this
|
|
|
|
* routine.
|
|
|
|
*/
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (!equal(info1->ii_Predicate, mapped))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* No support currently for comparing exclusion indexes. */
|
|
|
|
if (info1->ii_ExclusionOps != NULL || info2->ii_ExclusionOps != NULL)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
/* ----------------
|
|
|
|
* BuildSpeculativeIndexInfo
|
|
|
|
* Add extra state to IndexInfo record
|
|
|
|
*
|
|
|
|
* For unique indexes, we usually don't want to add info to the IndexInfo for
|
|
|
|
* checking uniqueness, since the B-Tree AM handles that directly. However,
|
|
|
|
* in the case of speculative insertion, additional support is required.
|
|
|
|
*
|
|
|
|
* Do this processing here rather than in BuildIndexInfo() to not incur the
|
|
|
|
* overhead in the common non-speculative cases.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
BuildSpeculativeIndexInfo(Relation index, IndexInfo *ii)
|
|
|
|
{
|
2016-04-08 20:52:13 +02:00
|
|
|
int ncols = index->rd_rel->relnatts;
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* fetch info for checking unique indexes
|
|
|
|
*/
|
|
|
|
Assert(ii->ii_Unique);
|
|
|
|
|
|
|
|
if (index->rd_rel->relam != BTREE_AM_OID)
|
|
|
|
elog(ERROR, "unexpected non-btree speculative unique index");
|
|
|
|
|
2016-04-08 20:52:13 +02:00
|
|
|
ii->ii_UniqueOps = (Oid *) palloc(sizeof(Oid) * ncols);
|
|
|
|
ii->ii_UniqueProcs = (Oid *) palloc(sizeof(Oid) * ncols);
|
|
|
|
ii->ii_UniqueStrats = (uint16 *) palloc(sizeof(uint16) * ncols);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
|
|
|
|
/*
|
2015-05-24 03:35:49 +02:00
|
|
|
* We have to look up the operator's strategy number. This provides a
|
|
|
|
* cross-check that the operator does match the index.
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
*/
|
|
|
|
/* We need the func OIDs and strategy numbers too */
|
2016-04-08 20:52:13 +02:00
|
|
|
for (i = 0; i < ncols; i++)
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
{
|
|
|
|
ii->ii_UniqueStrats[i] = BTEqualStrategyNumber;
|
|
|
|
ii->ii_UniqueOps[i] =
|
|
|
|
get_opfamily_member(index->rd_opfamily[i],
|
|
|
|
index->rd_opcintype[i],
|
|
|
|
index->rd_opcintype[i],
|
|
|
|
ii->ii_UniqueStrats[i]);
|
2017-07-24 17:23:27 +02:00
|
|
|
if (!OidIsValid(ii->ii_UniqueOps[i]))
|
|
|
|
elog(ERROR, "missing operator %d(%u,%u) in opfamily %u",
|
|
|
|
ii->ii_UniqueStrats[i], index->rd_opcintype[i],
|
|
|
|
index->rd_opcintype[i], index->rd_opfamily[i]);
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
ii->ii_UniqueProcs[i] = get_opcode(ii->ii_UniqueOps[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* FormIndexDatum
|
2005-03-21 02:24:04 +01:00
|
|
|
* Construct values[] and isnull[] arrays for a new index tuple.
|
2000-07-15 00:18:02 +02:00
|
|
|
*
|
|
|
|
* indexInfo Info about the index
|
2005-03-16 22:38:10 +01:00
|
|
|
* slot Heap tuple for which we must prepare an index entry
|
2003-05-28 18:04:02 +02:00
|
|
|
* estate executor state for evaluating any index expressions
|
2005-03-21 02:24:04 +01:00
|
|
|
* values Array of index Datums (output area)
|
|
|
|
* isnull Array of is-null indicators (output area)
|
2000-07-15 00:18:02 +02:00
|
|
|
*
|
2003-05-28 18:04:02 +02:00
|
|
|
* When there are no index expressions, estate may be NULL. Otherwise it
|
|
|
|
* must be supplied, *and* the ecxt_scantuple slot of its per-tuple expr
|
|
|
|
* context must point to the heap tuple passed in.
|
|
|
|
*
|
2005-03-21 02:24:04 +01:00
|
|
|
* Notice we don't actually call index_form_tuple() here; we just prepare
|
2014-05-06 18:12:18 +02:00
|
|
|
* its input arrays values[] and isnull[]. This is because the index AM
|
2005-03-21 02:24:04 +01:00
|
|
|
* may wish to alter the data before storage.
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2000-07-15 00:18:02 +02:00
|
|
|
FormIndexDatum(IndexInfo *indexInfo,
|
2005-03-16 22:38:10 +01:00
|
|
|
TupleTableSlot *slot,
|
2003-05-28 18:04:02 +02:00
|
|
|
EState *estate,
|
2005-03-21 02:24:04 +01:00
|
|
|
Datum *values,
|
|
|
|
bool *isnull)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *indexpr_item;
|
2000-07-15 00:18:02 +02:00
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
if (indexInfo->ii_Expressions != NIL &&
|
|
|
|
indexInfo->ii_ExpressionsState == NIL)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2003-05-28 18:04:02 +02:00
|
|
|
/* First time through, set up expression evaluation state */
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
indexInfo->ii_ExpressionsState =
|
|
|
|
ExecPrepareExprList(indexInfo->ii_Expressions, estate);
|
2003-05-28 18:04:02 +02:00
|
|
|
/* Check caller has set up context correctly */
|
2005-03-16 22:38:10 +01:00
|
|
|
Assert(GetPerTupleExprContext(estate)->ecxt_scantuple == slot);
|
2003-05-28 18:04:02 +02:00
|
|
|
}
|
2004-05-26 06:41:50 +02:00
|
|
|
indexpr_item = list_head(indexInfo->ii_ExpressionsState);
|
1998-09-09 05:42:52 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
for (i = 0; i < indexInfo->ii_NumIndexAttrs; i++)
|
|
|
|
{
|
|
|
|
int keycol = indexInfo->ii_KeyAttrNumbers[i];
|
|
|
|
Datum iDatum;
|
|
|
|
bool isNull;
|
1998-08-28 06:57:21 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
if (keycol != 0)
|
2000-07-15 00:18:02 +02:00
|
|
|
{
|
2003-05-28 18:04:02 +02:00
|
|
|
/*
|
|
|
|
* Plain index column; get the value we need directly from the
|
|
|
|
* heap tuple.
|
|
|
|
*/
|
2005-03-16 22:38:10 +01:00
|
|
|
iDatum = slot_getattr(slot, keycol, &isNull);
|
2000-07-15 00:18:02 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2003-05-28 18:04:02 +02:00
|
|
|
/*
|
|
|
|
* Index expression --- need to evaluate it.
|
|
|
|
*/
|
2004-05-26 06:41:50 +02:00
|
|
|
if (indexpr_item == NULL)
|
2003-05-28 18:04:02 +02:00
|
|
|
elog(ERROR, "wrong number of index expressions");
|
2004-05-26 06:41:50 +02:00
|
|
|
iDatum = ExecEvalExprSwitchContext((ExprState *) lfirst(indexpr_item),
|
2005-10-15 04:49:52 +02:00
|
|
|
GetPerTupleExprContext(estate),
|
2017-01-19 23:12:38 +01:00
|
|
|
&isNull);
|
2004-05-26 06:41:50 +02:00
|
|
|
indexpr_item = lnext(indexpr_item);
|
2000-07-15 00:18:02 +02:00
|
|
|
}
|
2005-03-21 02:24:04 +01:00
|
|
|
values[i] = iDatum;
|
|
|
|
isnull[i] = isNull;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2000-07-15 00:18:02 +02:00
|
|
|
|
2004-05-26 06:41:50 +02:00
|
|
|
if (indexpr_item != NULL)
|
2003-05-28 18:04:02 +02:00
|
|
|
elog(ERROR, "wrong number of index expressions");
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-05-11 01:18:39 +02:00
|
|
|
/*
|
2006-07-31 22:09:10 +02:00
|
|
|
* index_update_stats --- update pg_class entry after CREATE INDEX or REINDEX
|
2006-05-11 01:18:39 +02:00
|
|
|
*
|
|
|
|
* This routine updates the pg_class row of either an index or its parent
|
2014-05-06 18:12:18 +02:00
|
|
|
* relation after CREATE INDEX or REINDEX. Its rather bizarre API is designed
|
2006-07-31 22:09:10 +02:00
|
|
|
* to ensure we can do all the necessary work in just one update.
|
2000-11-08 23:10:03 +01:00
|
|
|
*
|
2006-05-11 01:18:39 +02:00
|
|
|
* hasindex: set relhasindex to this value
|
|
|
|
* isprimary: if true, set relhaspkey true; else no change
|
2011-10-14 23:23:01 +02:00
|
|
|
* reltuples: if >= 0, set reltuples to this value; else no change
|
2001-08-10 20:57:42 +02:00
|
|
|
*
|
2011-10-14 23:23:01 +02:00
|
|
|
* If reltuples >= 0, relpages and relallvisible are also updated (using
|
|
|
|
* RelationGetNumberOfBlocks() and visibilitymap_count()).
|
2001-08-10 20:57:42 +02:00
|
|
|
*
|
2000-11-08 23:10:03 +01:00
|
|
|
* NOTE: an important side-effect of this operation is that an SI invalidation
|
|
|
|
* message is sent out to all backends --- including me --- causing relcache
|
2014-05-06 18:12:18 +02:00
|
|
|
* entries to be flushed or updated with the new data. This must happen even
|
2006-05-11 01:18:39 +02:00
|
|
|
* if we find that no change is needed in the pg_class row. When updating
|
|
|
|
* a heap entry, this ensures that other backends find out about the new
|
|
|
|
* index. When updating an index, it's important because some index AMs
|
|
|
|
* expect a relcache flush to occur after REINDEX.
|
2000-02-18 10:30:20 +01:00
|
|
|
*/
|
2006-05-11 01:18:39 +02:00
|
|
|
static void
|
2009-12-07 06:22:23 +01:00
|
|
|
index_update_stats(Relation rel,
|
2013-07-03 20:24:09 +02:00
|
|
|
bool hasindex,
|
|
|
|
bool isprimary,
|
|
|
|
double reltuples)
|
2000-02-18 10:30:20 +01:00
|
|
|
{
|
2006-05-11 01:18:39 +02:00
|
|
|
Oid relid = RelationGetRelid(rel);
|
2000-02-18 10:30:20 +01:00
|
|
|
Relation pg_class;
|
|
|
|
HeapTuple tuple;
|
2006-05-11 01:18:39 +02:00
|
|
|
Form_pg_class rd_rel;
|
|
|
|
bool dirty;
|
2000-02-18 10:30:20 +01:00
|
|
|
|
2000-11-08 23:10:03 +01:00
|
|
|
/*
|
2006-07-31 22:09:10 +02:00
|
|
|
* We always update the pg_class row using a non-transactional,
|
|
|
|
* overwrite-in-place update. There are several reasons for this:
|
2006-05-11 01:18:39 +02:00
|
|
|
*
|
2006-07-31 22:09:10 +02:00
|
|
|
* 1. In bootstrap mode, we have no choice --- UPDATE wouldn't work.
|
|
|
|
*
|
2006-10-04 02:30:14 +02:00
|
|
|
* 2. We could be reindexing pg_class itself, in which case we can't move
|
2017-03-02 12:33:50 +01:00
|
|
|
* its pg_class row because CatalogTupleInsert/CatalogTupleUpdate might
|
|
|
|
* not know about all the indexes yet (see reindex_relation).
|
2006-07-31 22:09:10 +02:00
|
|
|
*
|
|
|
|
* 3. Because we execute CREATE INDEX with just share lock on the parent
|
|
|
|
* rel (to allow concurrent index creations), an ordinary update could
|
|
|
|
* suffer a tuple-concurrently-updated failure against another CREATE
|
|
|
|
* INDEX committing at about the same time. We can avoid that by having
|
|
|
|
* them both do nontransactional updates (we assume they will both be
|
|
|
|
* trying to change the pg_class row to the same thing, so it doesn't
|
|
|
|
* matter which goes first).
|
|
|
|
*
|
|
|
|
* It is safe to use a non-transactional update even though our
|
2014-05-06 18:12:18 +02:00
|
|
|
* transaction could still fail before committing. Setting relhasindex
|
2006-07-31 22:09:10 +02:00
|
|
|
* true is safe even if there are no indexes (VACUUM will eventually fix
|
2011-10-14 23:23:01 +02:00
|
|
|
* it), likewise for relhaspkey. And of course the new relpages and
|
|
|
|
* reltuples counts are correct regardless. However, we don't want to
|
|
|
|
* change relpages (or relallvisible) if the caller isn't providing an
|
|
|
|
* updated reltuples count, because that would bollix the
|
|
|
|
* reltuples/relpages ratio which is what's really important.
|
2000-02-18 10:30:20 +01:00
|
|
|
*/
|
|
|
|
|
2006-07-31 22:09:10 +02:00
|
|
|
pg_class = heap_open(RelationRelationId, RowExclusiveLock);
|
2006-05-11 01:18:39 +02:00
|
|
|
|
2006-07-31 22:09:10 +02:00
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Make a copy of the tuple to update. Normally we use the syscache, but
|
2006-10-04 02:30:14 +02:00
|
|
|
* we can't rely on that during bootstrap or while reindexing pg_class
|
|
|
|
* itself.
|
2006-07-31 22:09:10 +02:00
|
|
|
*/
|
|
|
|
if (IsBootstrapProcessingMode() ||
|
|
|
|
ReindexIsProcessingHeap(RelationRelationId))
|
2000-02-18 10:30:20 +01:00
|
|
|
{
|
2006-05-11 01:18:39 +02:00
|
|
|
/* don't assume syscache will work */
|
|
|
|
HeapScanDesc pg_class_scan;
|
2000-02-18 10:30:20 +01:00
|
|
|
ScanKeyData key[1];
|
|
|
|
|
2003-11-12 22:15:59 +01:00
|
|
|
ScanKeyInit(&key[0],
|
|
|
|
ObjectIdAttributeNumber,
|
|
|
|
BTEqualStrategyNumber, F_OIDEQ,
|
|
|
|
ObjectIdGetDatum(relid));
|
2000-02-18 10:30:20 +01:00
|
|
|
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
pg_class_scan = heap_beginscan_catalog(pg_class, 1, key);
|
2002-05-21 01:51:44 +02:00
|
|
|
tuple = heap_getnext(pg_class_scan, ForwardScanDirection);
|
2006-05-11 01:18:39 +02:00
|
|
|
tuple = heap_copytuple(tuple);
|
|
|
|
heap_endscan(pg_class_scan);
|
2000-02-18 10:30:20 +01:00
|
|
|
}
|
2006-07-31 22:09:10 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/* normal case, use syscache */
|
2010-02-14 19:42:19 +01:00
|
|
|
tuple = SearchSysCacheCopy1(RELOID, ObjectIdGetDatum(relid));
|
2006-07-31 22:09:10 +02:00
|
|
|
}
|
2000-02-18 10:30:20 +01:00
|
|
|
|
|
|
|
if (!HeapTupleIsValid(tuple))
|
2003-07-21 03:59:11 +02:00
|
|
|
elog(ERROR, "could not find tuple for relation %u", relid);
|
2006-05-11 01:18:39 +02:00
|
|
|
rd_rel = (Form_pg_class) GETSTRUCT(tuple);
|
2000-02-18 10:30:20 +01:00
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
/* Should this be a more comprehensive test? */
|
|
|
|
Assert(rd_rel->relkind != RELKIND_PARTITIONED_INDEX);
|
|
|
|
|
2006-05-11 01:18:39 +02:00
|
|
|
/* Apply required updates, if any, to copied tuple */
|
2001-08-10 20:57:42 +02:00
|
|
|
|
2006-05-11 01:18:39 +02:00
|
|
|
dirty = false;
|
|
|
|
if (rd_rel->relhasindex != hasindex)
|
2002-03-03 18:47:56 +01:00
|
|
|
{
|
2006-05-11 01:18:39 +02:00
|
|
|
rd_rel->relhasindex = hasindex;
|
2002-03-03 18:47:56 +01:00
|
|
|
dirty = true;
|
|
|
|
}
|
2001-08-10 20:57:42 +02:00
|
|
|
if (isprimary)
|
2002-03-03 18:47:56 +01:00
|
|
|
{
|
2006-05-11 01:18:39 +02:00
|
|
|
if (!rd_rel->relhaspkey)
|
2002-03-03 18:47:56 +01:00
|
|
|
{
|
2006-05-11 01:18:39 +02:00
|
|
|
rd_rel->relhaspkey = true;
|
2002-03-03 18:47:56 +01:00
|
|
|
dirty = true;
|
|
|
|
}
|
|
|
|
}
|
2011-10-14 23:23:01 +02:00
|
|
|
|
|
|
|
if (reltuples >= 0)
|
2000-02-18 10:30:20 +01:00
|
|
|
{
|
2011-10-14 23:23:01 +02:00
|
|
|
BlockNumber relpages = RelationGetNumberOfBlocks(rel);
|
|
|
|
BlockNumber relallvisible;
|
|
|
|
|
|
|
|
if (rd_rel->relkind != RELKIND_INDEX)
|
Change the format of the VM fork to add a second bit per page.
The new bit indicates whether every tuple on the page is already frozen.
It is cleared only when the all-visible bit is cleared, and it can be
set only when we vacuum a page and find that every tuple on that page is
both visible to every transaction and in no need of any future
vacuuming.
A future commit will use this new bit to optimize away full-table scans
that would otherwise be triggered by XID wraparound considerations. A
page which is merely all-visible must still be scanned in that case, but
a page which is all-frozen need not be. This commit does not attempt
that optimization, although that optimization is the goal here. It
seems better to get the basic infrastructure in place first.
Per discussion, it's very desirable for pg_upgrade to automatically
migrate existing VM forks from the old format to the new format. That,
too, will be handled in a follow-on patch.
Masahiko Sawada, reviewed by Kyotaro Horiguchi, Fujii Masao, Amit
Kapila, Simon Riggs, Andres Freund, and others, and substantially
revised by me.
2016-03-02 03:49:41 +01:00
|
|
|
visibilitymap_count(rel, &relallvisible, NULL);
|
2017-06-21 20:39:04 +02:00
|
|
|
else /* don't bother for indexes */
|
2011-10-14 23:23:01 +02:00
|
|
|
relallvisible = 0;
|
|
|
|
|
|
|
|
if (rd_rel->relpages != (int32) relpages)
|
|
|
|
{
|
|
|
|
rd_rel->relpages = (int32) relpages;
|
|
|
|
dirty = true;
|
|
|
|
}
|
|
|
|
if (rd_rel->reltuples != (float4) reltuples)
|
|
|
|
{
|
|
|
|
rd_rel->reltuples = (float4) reltuples;
|
|
|
|
dirty = true;
|
|
|
|
}
|
|
|
|
if (rd_rel->relallvisible != (int32) relallvisible)
|
|
|
|
{
|
|
|
|
rd_rel->relallvisible = (int32) relallvisible;
|
|
|
|
dirty = true;
|
|
|
|
}
|
2006-05-11 01:18:39 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If anything changed, write out the tuple
|
|
|
|
*/
|
|
|
|
if (dirty)
|
|
|
|
{
|
2006-07-31 22:09:10 +02:00
|
|
|
heap_inplace_update(pg_class, tuple);
|
|
|
|
/* the above sends a cache inval message */
|
2000-11-08 23:10:03 +01:00
|
|
|
}
|
2002-03-03 18:47:56 +01:00
|
|
|
else
|
|
|
|
{
|
2006-05-11 01:18:39 +02:00
|
|
|
/* no need to change tuple, but force relcache inval anyway */
|
2004-02-10 02:55:27 +01:00
|
|
|
CacheInvalidateRelcacheByTuple(tuple);
|
2002-03-03 18:47:56 +01:00
|
|
|
}
|
2000-06-17 23:49:04 +02:00
|
|
|
|
2006-05-11 01:18:39 +02:00
|
|
|
heap_freetuple(tuple);
|
2000-02-18 10:30:20 +01:00
|
|
|
|
2000-11-08 23:10:03 +01:00
|
|
|
heap_close(pg_class, RowExclusiveLock);
|
2000-02-18 10:30:20 +01:00
|
|
|
}
|
|
|
|
|
2000-12-08 07:17:58 +01:00
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
/*
|
|
|
|
* index_build - invoke access-method-specific index build procedure
|
2006-05-11 01:18:39 +02:00
|
|
|
*
|
|
|
|
* On entry, the index's catalog entries are valid, and its physical disk
|
2014-05-06 18:12:18 +02:00
|
|
|
* file has been created but is empty. We call the AM-specific build
|
2006-05-11 01:18:39 +02:00
|
|
|
* procedure to fill in the index contents. We then update the pg_class
|
|
|
|
* entries of the index and heap relation as needed, using statistics
|
|
|
|
* returned by ambuild as well as data passed by the caller.
|
|
|
|
*
|
2011-04-20 00:50:56 +02:00
|
|
|
* isprimary tells whether to mark the index as a primary-key index.
|
|
|
|
* isreindex indicates we are recreating a previously-existing index.
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
* parallel indicates if parallelism may be useful.
|
2011-04-20 00:50:56 +02:00
|
|
|
*
|
|
|
|
* Note: when reindexing an existing index, isprimary can be false even if
|
|
|
|
* the index is a PK; it's already properly marked and need not be re-marked.
|
2006-05-11 01:18:39 +02:00
|
|
|
*
|
|
|
|
* Note: before Postgres 8.2, the passed-in heap and index Relations
|
|
|
|
* were automatically closed by this routine. This is no longer the case.
|
|
|
|
* The caller opened 'em, and the caller should close 'em.
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
index_build(Relation heapRelation,
|
|
|
|
Relation indexRelation,
|
2006-05-11 01:18:39 +02:00
|
|
|
IndexInfo *indexInfo,
|
2011-04-20 00:50:56 +02:00
|
|
|
bool isprimary,
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
bool isreindex,
|
|
|
|
bool parallel)
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
{
|
2006-05-11 01:18:39 +02:00
|
|
|
IndexBuildResult *stats;
|
2008-01-03 22:23:15 +01:00
|
|
|
Oid save_userid;
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
int save_sec_context;
|
|
|
|
int save_nestlevel;
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* sanity checks
|
|
|
|
*/
|
|
|
|
Assert(RelationIsValid(indexRelation));
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
Assert(PointerIsValid(indexRelation->rd_amroutine));
|
|
|
|
Assert(PointerIsValid(indexRelation->rd_amroutine->ambuild));
|
|
|
|
Assert(PointerIsValid(indexRelation->rd_amroutine->ambuildempty));
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
/*
|
|
|
|
* Determine worker process details for parallel CREATE INDEX. Currently,
|
|
|
|
* only btree has support for parallel builds.
|
|
|
|
*
|
|
|
|
* Note that planner considers parallel safety for us.
|
|
|
|
*/
|
|
|
|
if (parallel && IsNormalProcessingMode() &&
|
|
|
|
indexRelation->rd_rel->relam == BTREE_AM_OID)
|
|
|
|
indexInfo->ii_ParallelWorkers =
|
|
|
|
plan_create_index_workers(RelationGetRelid(heapRelation),
|
|
|
|
RelationGetRelid(indexRelation));
|
|
|
|
|
|
|
|
if (indexInfo->ii_ParallelWorkers == 0)
|
|
|
|
ereport(DEBUG1,
|
|
|
|
(errmsg("building index \"%s\" on table \"%s\" serially",
|
|
|
|
RelationGetRelationName(indexRelation),
|
|
|
|
RelationGetRelationName(heapRelation))));
|
|
|
|
else
|
|
|
|
ereport(DEBUG1,
|
|
|
|
(errmsg_plural("building index \"%s\" on table \"%s\" with request for %d parallel worker",
|
|
|
|
"building index \"%s\" on table \"%s\" with request for %d parallel workers",
|
|
|
|
indexInfo->ii_ParallelWorkers,
|
|
|
|
RelationGetRelationName(indexRelation),
|
|
|
|
RelationGetRelationName(heapRelation),
|
|
|
|
indexInfo->ii_ParallelWorkers)));
|
2011-02-12 14:27:55 +01:00
|
|
|
|
2008-01-03 22:23:15 +01:00
|
|
|
/*
|
2009-06-11 16:49:15 +02:00
|
|
|
* Switch to the table owner's userid, so that any index functions are run
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
* as that user. Also lock down security-restricted operations and
|
|
|
|
* arrange to make GUC variable changes local to this command.
|
2008-01-03 22:23:15 +01:00
|
|
|
*/
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
GetUserIdAndSecContext(&save_userid, &save_sec_context);
|
|
|
|
SetUserIdAndSecContext(heapRelation->rd_rel->relowner,
|
|
|
|
save_sec_context | SECURITY_RESTRICTED_OPERATION);
|
|
|
|
save_nestlevel = NewGUCNestLevel();
|
2008-01-03 22:23:15 +01:00
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
/*
|
|
|
|
* Call the access method's build procedure
|
|
|
|
*/
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
stats = indexRelation->rd_amroutine->ambuild(heapRelation, indexRelation,
|
|
|
|
indexInfo);
|
2006-05-11 01:18:39 +02:00
|
|
|
Assert(PointerIsValid(stats));
|
|
|
|
|
2010-12-29 12:48:53 +01:00
|
|
|
/*
|
2011-06-02 19:28:52 +02:00
|
|
|
* If this is an unlogged index, we may need to write out an init fork for
|
|
|
|
* it -- but we must first check whether one already exists. If, for
|
|
|
|
* example, an unlogged relation is truncated in the transaction that
|
|
|
|
* created it, or truncated twice in a subsequent transaction, the
|
|
|
|
* relfilenode won't change, and nothing needs to be done here.
|
2010-12-29 12:48:53 +01:00
|
|
|
*/
|
2014-11-15 05:19:49 +01:00
|
|
|
if (indexRelation->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED &&
|
2011-06-06 04:30:04 +02:00
|
|
|
!smgrexists(indexRelation->rd_smgr, INIT_FORKNUM))
|
2010-12-29 12:48:53 +01:00
|
|
|
{
|
|
|
|
RelationOpenSmgr(indexRelation);
|
|
|
|
smgrcreate(indexRelation->rd_smgr, INIT_FORKNUM, false);
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
indexRelation->rd_amroutine->ambuildempty(indexRelation);
|
2010-12-29 12:48:53 +01:00
|
|
|
}
|
|
|
|
|
2007-09-20 19:56:33 +02:00
|
|
|
/*
|
2007-11-15 22:14:46 +01:00
|
|
|
* If we found any potentially broken HOT chains, mark the index as not
|
|
|
|
* being usable until the current transaction is below the event horizon.
|
2016-06-10 16:25:31 +02:00
|
|
|
* See src/backend/access/heap/README.HOT for discussion. Also set this
|
|
|
|
* if early pruning/vacuuming is enabled for the heap relation. While it
|
|
|
|
* might become safe to use the index earlier based on actual cleanup
|
|
|
|
* activity and other active transactions, the test for that would be much
|
|
|
|
* more complex and would require some form of blocking, so keep it simple
|
|
|
|
* and fast by just using the current transaction.
|
2011-04-20 00:50:56 +02:00
|
|
|
*
|
|
|
|
* However, when reindexing an existing index, we should do nothing here.
|
|
|
|
* Any HOT chains that are broken with respect to the index must predate
|
|
|
|
* the index's original creation, so there is no need to change the
|
2011-06-09 20:32:50 +02:00
|
|
|
* index's usability horizon. Moreover, we *must not* try to change the
|
|
|
|
* index's pg_index entry while reindexing pg_index itself, and this
|
2016-06-10 16:25:31 +02:00
|
|
|
* optimization nicely prevents that. The more complex rules needed for a
|
|
|
|
* reindex are handled separately after this function returns.
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
*
|
|
|
|
* We also need not set indcheckxmin during a concurrent index build,
|
|
|
|
* because we won't set indisvalid true until all transactions that care
|
2016-06-10 16:25:31 +02:00
|
|
|
* about the broken HOT chains or early pruning/vacuuming are gone.
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
*
|
|
|
|
* Therefore, this code path can only be taken during non-concurrent
|
|
|
|
* CREATE INDEX. Thus the fact that heap_update will set the pg_index
|
|
|
|
* tuple's xmin doesn't matter, because that tuple was created in the
|
2014-05-06 18:12:18 +02:00
|
|
|
* current transaction anyway. That also means we don't need to worry
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* about any concurrent readers of the tuple; no other transaction can see
|
|
|
|
* it yet.
|
|
|
|
*/
|
2016-06-10 16:25:31 +02:00
|
|
|
if ((indexInfo->ii_BrokenHotChain || EarlyPruningEnabled(heapRelation)) &&
|
|
|
|
!isreindex &&
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
!indexInfo->ii_Concurrent)
|
2007-09-20 19:56:33 +02:00
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
Oid indexId = RelationGetRelid(indexRelation);
|
|
|
|
Relation pg_index;
|
|
|
|
HeapTuple indexTuple;
|
2007-09-20 19:56:33 +02:00
|
|
|
Form_pg_index indexForm;
|
|
|
|
|
|
|
|
pg_index = heap_open(IndexRelationId, RowExclusiveLock);
|
|
|
|
|
2010-02-14 19:42:19 +01:00
|
|
|
indexTuple = SearchSysCacheCopy1(INDEXRELID,
|
|
|
|
ObjectIdGetDatum(indexId));
|
2007-09-20 19:56:33 +02:00
|
|
|
if (!HeapTupleIsValid(indexTuple))
|
|
|
|
elog(ERROR, "cache lookup failed for index %u", indexId);
|
|
|
|
indexForm = (Form_pg_index) GETSTRUCT(indexTuple);
|
|
|
|
|
2011-04-20 00:50:56 +02:00
|
|
|
/* If it's a new index, indcheckxmin shouldn't be set ... */
|
|
|
|
Assert(!indexForm->indcheckxmin);
|
|
|
|
|
2007-09-20 19:56:33 +02:00
|
|
|
indexForm->indcheckxmin = true;
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(pg_index, &indexTuple->t_self, indexTuple);
|
2007-09-20 19:56:33 +02:00
|
|
|
|
|
|
|
heap_freetuple(indexTuple);
|
|
|
|
heap_close(pg_index, RowExclusiveLock);
|
|
|
|
}
|
|
|
|
|
2006-05-11 01:18:39 +02:00
|
|
|
/*
|
|
|
|
* Update heap and index pg_class rows
|
|
|
|
*/
|
|
|
|
index_update_stats(heapRelation,
|
|
|
|
true,
|
|
|
|
isprimary,
|
|
|
|
stats->heap_tuples);
|
|
|
|
|
|
|
|
index_update_stats(indexRelation,
|
|
|
|
false,
|
|
|
|
false,
|
|
|
|
stats->index_tuples);
|
|
|
|
|
2011-06-06 04:30:04 +02:00
|
|
|
/* Make the updated catalog row versions visible */
|
2006-05-11 01:18:39 +02:00
|
|
|
CommandCounterIncrement();
|
2011-06-06 04:30:04 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If it's for an exclusion constraint, make a second pass over the heap
|
2014-05-06 18:12:18 +02:00
|
|
|
* to verify that the constraint is satisfied. We must not do this until
|
2011-06-06 04:30:04 +02:00
|
|
|
* the index is fully valid. (Broken HOT chains shouldn't matter, though;
|
|
|
|
* see comments for IndexCheckExclusion.)
|
|
|
|
*/
|
|
|
|
if (indexInfo->ii_ExclusionOps != NULL)
|
|
|
|
IndexCheckExclusion(heapRelation, indexRelation, indexInfo);
|
|
|
|
|
|
|
|
/* Roll back any GUC changes executed by index functions */
|
|
|
|
AtEOXact_GUC(false, save_nestlevel);
|
|
|
|
|
|
|
|
/* Restore userid and security context */
|
|
|
|
SetUserIdAndSecContext(save_userid, save_sec_context);
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* IndexBuildHeapScan - scan the heap relation to find tuples to be indexed
|
2000-06-18 01:41:51 +02:00
|
|
|
*
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
* This is called back from an access-method-specific index build procedure
|
|
|
|
* after the AM has done whatever setup it needs. The parent heap relation
|
|
|
|
* is scanned to find tuples that should be entered into the index. Each
|
|
|
|
* such tuple is passed to the AM's callback routine, which does the right
|
|
|
|
* things to add it to the new index. After we return, the AM's index
|
2009-12-07 06:22:23 +01:00
|
|
|
* build procedure does whatever cleanup it needs.
|
2000-06-18 01:41:51 +02:00
|
|
|
*
|
2014-05-06 18:12:18 +02:00
|
|
|
* The total count of heap tuples is returned. This is for updating pg_class
|
|
|
|
* statistics. (It's annoying not to be able to do that here, but we want
|
2009-12-07 06:22:23 +01:00
|
|
|
* to merge that update with others; see index_update_stats.) Note that the
|
|
|
|
* index AM itself must keep track of the number of index tuples; we don't do
|
|
|
|
* so here because the AM might reject some of the tuples for its own reasons,
|
|
|
|
* such as being unable to store NULLs.
|
2007-09-20 19:56:33 +02:00
|
|
|
*
|
|
|
|
* A side effect is to set indexInfo->ii_BrokenHotChain to true if we detect
|
|
|
|
* any potentially broken HOT chains. Currently, we set this if there are
|
2011-04-21 02:34:11 +02:00
|
|
|
* any RECENTLY_DEAD or DELETE_IN_PROGRESS entries in a HOT chain, without
|
|
|
|
* trying very hard to detect whether they're really incompatible with the
|
|
|
|
* chain tip.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
double
|
|
|
|
IndexBuildHeapScan(Relation heapRelation,
|
|
|
|
Relation indexRelation,
|
|
|
|
IndexInfo *indexInfo,
|
2008-11-13 18:42:10 +01:00
|
|
|
bool allow_sync,
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
IndexBuildCallback callback,
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
void *callback_state,
|
|
|
|
HeapScanDesc scan)
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
{
|
|
|
|
return IndexBuildHeapRangeScan(heapRelation, indexRelation,
|
|
|
|
indexInfo, allow_sync,
|
Fix BRIN to use SnapshotAny during summarization
For correctness of summarization results, it is critical that the
snapshot used during the summarization scan is able to see all tuples
that are live to all transactions -- including tuples inserted or
deleted by in-progress transactions. Otherwise, it would be possible
for a transaction to insert a tuple, then idle for a long time while a
concurrent transaction executes summarization of the range: this would
result in the inserted value not being considered in the summary.
Previously we were trying to use a MVCC snapshot in conjunction with
adding a "placeholder" tuple in the index: the snapshot would see all
committed tuples, and the placeholder tuple would catch insertions by
any new inserters. The hole is that prior insertions by transactions
that are still in progress by the time the MVCC snapshot was taken were
ignored.
Kevin Grittner reported this as a bogus error message during vacuum with
default transaction isolation mode set to repeatable read (because the
error report mentioned a function name not being invoked during), but
the problem is larger than that.
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves
the way we need using SnapshotAny visibility rules. This change
simplifies the BRIN code a bit, mainly by removing large comments that
were mistaken. Instead, rely on the SnapshotAny semantics to provide
what it needs. (The business about a placeholder tuple needs to remain:
that covers the case that a transaction inserts a a tuple in a page that
summarization already scanned.)
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org
In passing, remove a couple of unused declarations from brin.h and
reword a comment to be proper English. This part submitted by Kevin
Grittner.
Backpatch to 9.5, where BRIN was introduced.
2015-08-05 21:20:50 +02:00
|
|
|
false,
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
0, InvalidBlockNumber,
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
callback, callback_state, scan);
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* As above, except that instead of scanning the complete heap, only the given
|
|
|
|
* number of blocks are scanned. Scan to end-of-rel can be signalled by
|
2015-07-21 19:38:24 +02:00
|
|
|
* passing InvalidBlockNumber as numblocks. Note that restricting the range
|
|
|
|
* to scan cannot be done when requesting syncscan.
|
Fix BRIN to use SnapshotAny during summarization
For correctness of summarization results, it is critical that the
snapshot used during the summarization scan is able to see all tuples
that are live to all transactions -- including tuples inserted or
deleted by in-progress transactions. Otherwise, it would be possible
for a transaction to insert a tuple, then idle for a long time while a
concurrent transaction executes summarization of the range: this would
result in the inserted value not being considered in the summary.
Previously we were trying to use a MVCC snapshot in conjunction with
adding a "placeholder" tuple in the index: the snapshot would see all
committed tuples, and the placeholder tuple would catch insertions by
any new inserters. The hole is that prior insertions by transactions
that are still in progress by the time the MVCC snapshot was taken were
ignored.
Kevin Grittner reported this as a bogus error message during vacuum with
default transaction isolation mode set to repeatable read (because the
error report mentioned a function name not being invoked during), but
the problem is larger than that.
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves
the way we need using SnapshotAny visibility rules. This change
simplifies the BRIN code a bit, mainly by removing large comments that
were mistaken. Instead, rely on the SnapshotAny semantics to provide
what it needs. (The business about a placeholder tuple needs to remain:
that covers the case that a transaction inserts a a tuple in a page that
summarization already scanned.)
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org
In passing, remove a couple of unused declarations from brin.h and
reword a comment to be proper English. This part submitted by Kevin
Grittner.
Backpatch to 9.5, where BRIN was introduced.
2015-08-05 21:20:50 +02:00
|
|
|
*
|
|
|
|
* When "anyvisible" mode is requested, all tuples visible to any transaction
|
|
|
|
* are considered, including those inserted or deleted by transactions that are
|
|
|
|
* still in progress.
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
*/
|
|
|
|
double
|
|
|
|
IndexBuildHeapRangeScan(Relation heapRelation,
|
|
|
|
Relation indexRelation,
|
|
|
|
IndexInfo *indexInfo,
|
|
|
|
bool allow_sync,
|
Fix BRIN to use SnapshotAny during summarization
For correctness of summarization results, it is critical that the
snapshot used during the summarization scan is able to see all tuples
that are live to all transactions -- including tuples inserted or
deleted by in-progress transactions. Otherwise, it would be possible
for a transaction to insert a tuple, then idle for a long time while a
concurrent transaction executes summarization of the range: this would
result in the inserted value not being considered in the summary.
Previously we were trying to use a MVCC snapshot in conjunction with
adding a "placeholder" tuple in the index: the snapshot would see all
committed tuples, and the placeholder tuple would catch insertions by
any new inserters. The hole is that prior insertions by transactions
that are still in progress by the time the MVCC snapshot was taken were
ignored.
Kevin Grittner reported this as a bogus error message during vacuum with
default transaction isolation mode set to repeatable read (because the
error report mentioned a function name not being invoked during), but
the problem is larger than that.
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves
the way we need using SnapshotAny visibility rules. This change
simplifies the BRIN code a bit, mainly by removing large comments that
were mistaken. Instead, rely on the SnapshotAny semantics to provide
what it needs. (The business about a placeholder tuple needs to remain:
that covers the case that a transaction inserts a a tuple in a page that
summarization already scanned.)
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org
In passing, remove a couple of unused declarations from brin.h and
reword a comment to be proper English. This part submitted by Kevin
Grittner.
Backpatch to 9.5, where BRIN was introduced.
2015-08-05 21:20:50 +02:00
|
|
|
bool anyvisible,
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
BlockNumber start_blockno,
|
|
|
|
BlockNumber numblocks,
|
|
|
|
IndexBuildCallback callback,
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
void *callback_state,
|
|
|
|
HeapScanDesc scan)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2010-02-07 23:40:33 +01:00
|
|
|
bool is_system_catalog;
|
|
|
|
bool checking_uniqueness;
|
1997-09-08 04:41:22 +02:00
|
|
|
HeapTuple heapTuple;
|
2005-03-21 02:24:04 +01:00
|
|
|
Datum values[INDEX_MAX_KEYS];
|
|
|
|
bool isnull[INDEX_MAX_KEYS];
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
double reltuples;
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExprState *predicate;
|
1997-09-07 07:04:48 +02:00
|
|
|
TupleTableSlot *slot;
|
2002-12-15 17:17:59 +01:00
|
|
|
EState *estate;
|
2000-07-15 00:18:02 +02:00
|
|
|
ExprContext *econtext;
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
Snapshot snapshot;
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
bool need_unregister_snapshot = false;
|
2001-08-26 18:56:03 +02:00
|
|
|
TransactionId OldestXmin;
|
2007-09-20 19:56:33 +02:00
|
|
|
BlockNumber root_blkno = InvalidBlockNumber;
|
|
|
|
OffsetNumber root_offsets[MaxHeapTuplesPerPage];
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
* sanity checks
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
Assert(OidIsValid(indexRelation->rd_rel->relam));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2010-02-07 23:40:33 +01:00
|
|
|
/* Remember if it's a system catalog */
|
|
|
|
is_system_catalog = IsSystemRelation(heapRelation);
|
|
|
|
|
|
|
|
/* See whether we're verifying uniqueness/exclusion properties */
|
|
|
|
checking_uniqueness = (indexInfo->ii_Unique ||
|
|
|
|
indexInfo->ii_ExclusionOps != NULL);
|
|
|
|
|
Fix BRIN to use SnapshotAny during summarization
For correctness of summarization results, it is critical that the
snapshot used during the summarization scan is able to see all tuples
that are live to all transactions -- including tuples inserted or
deleted by in-progress transactions. Otherwise, it would be possible
for a transaction to insert a tuple, then idle for a long time while a
concurrent transaction executes summarization of the range: this would
result in the inserted value not being considered in the summary.
Previously we were trying to use a MVCC snapshot in conjunction with
adding a "placeholder" tuple in the index: the snapshot would see all
committed tuples, and the placeholder tuple would catch insertions by
any new inserters. The hole is that prior insertions by transactions
that are still in progress by the time the MVCC snapshot was taken were
ignored.
Kevin Grittner reported this as a bogus error message during vacuum with
default transaction isolation mode set to repeatable read (because the
error report mentioned a function name not being invoked during), but
the problem is larger than that.
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves
the way we need using SnapshotAny visibility rules. This change
simplifies the BRIN code a bit, mainly by removing large comments that
were mistaken. Instead, rely on the SnapshotAny semantics to provide
what it needs. (The business about a placeholder tuple needs to remain:
that covers the case that a transaction inserts a a tuple in a page that
summarization already scanned.)
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org
In passing, remove a couple of unused declarations from brin.h and
reword a comment to be proper English. This part submitted by Kevin
Grittner.
Backpatch to 9.5, where BRIN was introduced.
2015-08-05 21:20:50 +02:00
|
|
|
/*
|
|
|
|
* "Any visible" mode is not compatible with uniqueness checks; make sure
|
|
|
|
* only one of those is requested.
|
|
|
|
*/
|
|
|
|
Assert(!(anyvisible && checking_uniqueness));
|
|
|
|
|
2002-12-15 17:17:59 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Need an EState for evaluation of index expressions and partial-index
|
2014-05-06 18:12:18 +02:00
|
|
|
* predicates. Also a slot to hold the current tuple.
|
2002-12-15 17:17:59 +01:00
|
|
|
*/
|
|
|
|
estate = CreateExecutorState();
|
|
|
|
econtext = GetPerTupleExprContext(estate);
|
2005-03-16 22:38:10 +01:00
|
|
|
slot = MakeSingleTupleTableSlot(RelationGetDescr(heapRelation));
|
2002-12-15 17:17:59 +01:00
|
|
|
|
2005-03-16 22:38:10 +01:00
|
|
|
/* Arrange for econtext's scan tuple to be the tuple under test */
|
|
|
|
econtext->ecxt_scantuple = slot;
|
2002-12-15 17:17:59 +01:00
|
|
|
|
2005-03-16 22:38:10 +01:00
|
|
|
/* Set up execution state for predicate, if any. */
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
predicate = ExecPrepareQual(indexInfo->ii_Predicate, estate);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* Prepare for scan of the base relation. In a normal index build, we use
|
|
|
|
* SnapshotAny because we must retrieve all tuples and do our own time
|
|
|
|
* qual checks (because we have to index RECENTLY_DEAD tuples). In a
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
* concurrent build, or during bootstrap, we take a regular MVCC snapshot
|
|
|
|
* and index whatever's live according to that.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
OldestXmin = InvalidTransactionId;
|
|
|
|
|
|
|
|
/* okay to ignore lazy VACUUMs here */
|
|
|
|
if (!IsBootstrapProcessingMode() && !indexInfo->ii_Concurrent)
|
|
|
|
OldestXmin = GetOldestXmin(heapRelation, PROCARRAY_FLAGS_VACUUM);
|
Fix BRIN to use SnapshotAny during summarization
For correctness of summarization results, it is critical that the
snapshot used during the summarization scan is able to see all tuples
that are live to all transactions -- including tuples inserted or
deleted by in-progress transactions. Otherwise, it would be possible
for a transaction to insert a tuple, then idle for a long time while a
concurrent transaction executes summarization of the range: this would
result in the inserted value not being considered in the summary.
Previously we were trying to use a MVCC snapshot in conjunction with
adding a "placeholder" tuple in the index: the snapshot would see all
committed tuples, and the placeholder tuple would catch insertions by
any new inserters. The hole is that prior insertions by transactions
that are still in progress by the time the MVCC snapshot was taken were
ignored.
Kevin Grittner reported this as a bogus error message during vacuum with
default transaction isolation mode set to repeatable read (because the
error report mentioned a function name not being invoked during), but
the problem is larger than that.
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves
the way we need using SnapshotAny visibility rules. This change
simplifies the BRIN code a bit, mainly by removing large comments that
were mistaken. Instead, rely on the SnapshotAny semantics to provide
what it needs. (The business about a placeholder tuple needs to remain:
that covers the case that a transaction inserts a a tuple in a page that
summarization already scanned.)
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org
In passing, remove a couple of unused declarations from brin.h and
reword a comment to be proper English. This part submitted by Kevin
Grittner.
Backpatch to 9.5, where BRIN was introduced.
2015-08-05 21:20:50 +02:00
|
|
|
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
if (!scan)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Serial index build.
|
|
|
|
*
|
|
|
|
* Must begin our own heap scan in this case. We may also need to
|
|
|
|
* register a snapshot whose lifetime is under our direct control.
|
|
|
|
*/
|
|
|
|
if (!TransactionIdIsValid(OldestXmin))
|
|
|
|
{
|
|
|
|
snapshot = RegisterSnapshot(GetTransactionSnapshot());
|
|
|
|
need_unregister_snapshot = true;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
snapshot = SnapshotAny;
|
|
|
|
|
|
|
|
scan = heap_beginscan_strat(heapRelation, /* relation */
|
|
|
|
snapshot, /* snapshot */
|
|
|
|
0, /* number of keys */
|
|
|
|
NULL, /* scan key */
|
|
|
|
true, /* buffer access strategy OK */
|
|
|
|
allow_sync); /* syncscan OK? */
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
/*
|
|
|
|
* Parallel index build.
|
|
|
|
*
|
|
|
|
* Parallel case never registers/unregisters own snapshot. Snapshot
|
|
|
|
* is taken from parallel heap scan, and is SnapshotAny or an MVCC
|
|
|
|
* snapshot, based on same criteria as serial case.
|
|
|
|
*/
|
|
|
|
Assert(!IsBootstrapProcessingMode());
|
|
|
|
Assert(allow_sync);
|
|
|
|
snapshot = scan->rs_snapshot;
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
}
|
|
|
|
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
/*
|
|
|
|
* Must call GetOldestXmin() with SnapshotAny. Should never call
|
|
|
|
* GetOldestXmin() with MVCC snapshot. (It's especially worth checking
|
|
|
|
* this for parallel builds, since ambuild routines that support parallel
|
|
|
|
* builds must work these details out for themselves.)
|
|
|
|
*/
|
|
|
|
Assert(snapshot == SnapshotAny || IsMVCCSnapshot(snapshot));
|
|
|
|
Assert(snapshot == SnapshotAny ? TransactionIdIsValid(OldestXmin) :
|
|
|
|
!TransactionIdIsValid(OldestXmin));
|
|
|
|
Assert(snapshot == SnapshotAny || !anyvisible);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
/* set our scan endpoints */
|
2015-07-21 19:38:24 +02:00
|
|
|
if (!allow_sync)
|
|
|
|
heap_setscanlimits(scan, start_blockno, numblocks);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* syncscan can only be requested on whole relation */
|
|
|
|
Assert(start_blockno == 0);
|
|
|
|
Assert(numblocks == InvalidBlockNumber);
|
|
|
|
}
|
BRIN: Block Range Indexes
BRIN is a new index access method intended to accelerate scans of very
large tables, without the maintenance overhead of btrees or other
traditional indexes. They work by maintaining "summary" data about
block ranges. Bitmap index scans work by reading each summary tuple and
comparing them with the query quals; all pages in the range are returned
in a lossy TID bitmap if the quals are consistent with the values in the
summary tuple, otherwise not. Normal index scans are not supported
because these indexes do not store TIDs.
As new tuples are added into the index, the summary information is
updated (if the block range in which the tuple is added is already
summarized) or not; in the latter case, a subsequent pass of VACUUM or
the brin_summarize_new_values() function will create the summary
information.
For data types with natural 1-D sort orders, the summary info consists
of the maximum and the minimum values of each indexed column within each
page range. This type of operator class we call "Minmax", and we
supply a bunch of them for most data types with B-tree opclasses.
Since the BRIN code is generalized, other approaches are possible for
things such as arrays, geometric types, ranges, etc; even for things
such as enum types we could do something different than minmax with
better results. In this commit I only include minmax.
Catalog version bumped due to new builtin catalog entries.
There's more that could be done here, but this is a good step forwards.
Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera,
with contribution by Heikki Linnakangas.
Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas.
Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo.
PS:
The research leading to these results has received funding from the
European Union's Seventh Framework Programme (FP7/2007-2013) under
grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
reltuples = 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
* Scan all tuples in the base relation.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2002-05-21 01:51:44 +02:00
|
|
|
while ((heapTuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
bool tupleIsAlive;
|
2000-07-15 00:18:02 +02:00
|
|
|
|
2002-01-06 01:37:44 +01:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2007-09-20 19:56:33 +02:00
|
|
|
/*
|
2007-11-15 22:14:46 +01:00
|
|
|
* When dealing with a HOT-chain of updated tuples, we want to index
|
|
|
|
* the values of the live tuple (if any), but index it under the TID
|
|
|
|
* of the chain's root tuple. This approach is necessary to preserve
|
|
|
|
* the HOT-chain structure in the heap. So we need to be able to find
|
|
|
|
* the root item offset for every tuple that's in a HOT-chain. When
|
|
|
|
* first reaching a new page of the relation, call
|
|
|
|
* heap_get_root_tuples() to build a map of root item offsets on the
|
|
|
|
* page.
|
2007-09-20 19:56:33 +02:00
|
|
|
*
|
|
|
|
* It might look unsafe to use this information across buffer
|
|
|
|
* lock/unlock. However, we hold ShareLock on the table so no
|
2007-11-15 22:14:46 +01:00
|
|
|
* ordinary insert/update/delete should occur; and we hold pin on the
|
|
|
|
* buffer continuously while visiting the page, so no pruning
|
2007-09-20 19:56:33 +02:00
|
|
|
* operation can occur either.
|
|
|
|
*
|
2011-04-21 02:34:11 +02:00
|
|
|
* Also, although our opinions about tuple liveness could change while
|
|
|
|
* we scan the page (due to concurrent transaction commits/aborts),
|
|
|
|
* the chain root locations won't, so this info doesn't need to be
|
|
|
|
* rebuilt after waiting for another transaction.
|
|
|
|
*
|
2007-09-20 19:56:33 +02:00
|
|
|
* Note the implied assumption that there is no more than one live
|
2011-04-21 02:34:11 +02:00
|
|
|
* tuple per HOT-chain --- else we could create more than one index
|
|
|
|
* entry pointing to the same root tuple.
|
2007-09-20 19:56:33 +02:00
|
|
|
*/
|
|
|
|
if (scan->rs_cblock != root_blkno)
|
|
|
|
{
|
2016-04-20 15:31:19 +02:00
|
|
|
Page page = BufferGetPage(scan->rs_cbuf);
|
2007-09-20 19:56:33 +02:00
|
|
|
|
|
|
|
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_SHARE);
|
|
|
|
heap_get_root_tuples(page, root_offsets);
|
|
|
|
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_UNLOCK);
|
|
|
|
|
|
|
|
root_blkno = scan->rs_cblock;
|
|
|
|
}
|
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
if (snapshot == SnapshotAny)
|
|
|
|
{
|
|
|
|
/* do our own time qual check */
|
2001-10-25 07:50:21 +02:00
|
|
|
bool indexIt;
|
2010-02-07 23:40:33 +01:00
|
|
|
TransactionId xwait;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2007-11-15 22:14:46 +01:00
|
|
|
recheck:
|
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
/*
|
2004-10-16 00:40:29 +02:00
|
|
|
* We could possibly get away with not locking the buffer here,
|
|
|
|
* since caller should hold ShareLock on the relation, but let's
|
2007-11-15 22:14:46 +01:00
|
|
|
* be conservative about it. (This remark is still correct even
|
|
|
|
* with HOT-pruning: our pin on the buffer prevents pruning.)
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
*/
|
|
|
|
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_SHARE);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2013-07-22 19:26:33 +02:00
|
|
|
switch (HeapTupleSatisfiesVacuum(heapTuple, OldestXmin,
|
2004-10-16 00:40:29 +02:00
|
|
|
scan->rs_cbuf))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
case HEAPTUPLE_DEAD:
|
2006-08-25 06:06:58 +02:00
|
|
|
/* Definitely dead, we can ignore it */
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
indexIt = false;
|
|
|
|
tupleIsAlive = false;
|
|
|
|
break;
|
|
|
|
case HEAPTUPLE_LIVE:
|
2006-08-25 06:06:58 +02:00
|
|
|
/* Normal case, index and unique-check it */
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
indexIt = true;
|
|
|
|
tupleIsAlive = true;
|
|
|
|
break;
|
|
|
|
case HEAPTUPLE_RECENTLY_DEAD:
|
2001-10-25 07:50:21 +02:00
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
/*
|
|
|
|
* If tuple is recently deleted then we must index it
|
2006-03-25 00:02:17 +01:00
|
|
|
* anyway to preserve MVCC semantics. (Pre-existing
|
2006-10-04 02:30:14 +02:00
|
|
|
* transactions could try to use the index after we finish
|
2007-09-20 19:56:33 +02:00
|
|
|
* building it, and may need to see such tuples.)
|
|
|
|
*
|
|
|
|
* However, if it was HOT-updated then we must only index
|
2014-05-06 18:12:18 +02:00
|
|
|
* the live tuple at the end of the HOT-chain. Since this
|
2007-11-15 22:14:46 +01:00
|
|
|
* breaks semantics for pre-existing snapshots, mark the
|
|
|
|
* index as unusable for them.
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
*/
|
2007-09-20 19:56:33 +02:00
|
|
|
if (HeapTupleIsHotUpdated(heapTuple))
|
|
|
|
{
|
|
|
|
indexIt = false;
|
|
|
|
/* mark the index as unsafe for old snapshots */
|
2011-04-19 22:55:34 +02:00
|
|
|
indexInfo->ii_BrokenHotChain = true;
|
2007-09-20 19:56:33 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
indexIt = true;
|
|
|
|
/* In any case, exclude the tuple from unique-checking */
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
tupleIsAlive = false;
|
|
|
|
break;
|
|
|
|
case HEAPTUPLE_INSERT_IN_PROGRESS:
|
2001-10-25 07:50:21 +02:00
|
|
|
|
Fix BRIN to use SnapshotAny during summarization
For correctness of summarization results, it is critical that the
snapshot used during the summarization scan is able to see all tuples
that are live to all transactions -- including tuples inserted or
deleted by in-progress transactions. Otherwise, it would be possible
for a transaction to insert a tuple, then idle for a long time while a
concurrent transaction executes summarization of the range: this would
result in the inserted value not being considered in the summary.
Previously we were trying to use a MVCC snapshot in conjunction with
adding a "placeholder" tuple in the index: the snapshot would see all
committed tuples, and the placeholder tuple would catch insertions by
any new inserters. The hole is that prior insertions by transactions
that are still in progress by the time the MVCC snapshot was taken were
ignored.
Kevin Grittner reported this as a bogus error message during vacuum with
default transaction isolation mode set to repeatable read (because the
error report mentioned a function name not being invoked during), but
the problem is larger than that.
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves
the way we need using SnapshotAny visibility rules. This change
simplifies the BRIN code a bit, mainly by removing large comments that
were mistaken. Instead, rely on the SnapshotAny semantics to provide
what it needs. (The business about a placeholder tuple needs to remain:
that covers the case that a transaction inserts a a tuple in a page that
summarization already scanned.)
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org
In passing, remove a couple of unused declarations from brin.h and
reword a comment to be proper English. This part submitted by Kevin
Grittner.
Backpatch to 9.5, where BRIN was introduced.
2015-08-05 21:20:50 +02:00
|
|
|
/*
|
2016-01-18 01:13:18 +01:00
|
|
|
* In "anyvisible" mode, this tuple is visible and we
|
|
|
|
* don't need any further checks.
|
Fix BRIN to use SnapshotAny during summarization
For correctness of summarization results, it is critical that the
snapshot used during the summarization scan is able to see all tuples
that are live to all transactions -- including tuples inserted or
deleted by in-progress transactions. Otherwise, it would be possible
for a transaction to insert a tuple, then idle for a long time while a
concurrent transaction executes summarization of the range: this would
result in the inserted value not being considered in the summary.
Previously we were trying to use a MVCC snapshot in conjunction with
adding a "placeholder" tuple in the index: the snapshot would see all
committed tuples, and the placeholder tuple would catch insertions by
any new inserters. The hole is that prior insertions by transactions
that are still in progress by the time the MVCC snapshot was taken were
ignored.
Kevin Grittner reported this as a bogus error message during vacuum with
default transaction isolation mode set to repeatable read (because the
error report mentioned a function name not being invoked during), but
the problem is larger than that.
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves
the way we need using SnapshotAny visibility rules. This change
simplifies the BRIN code a bit, mainly by removing large comments that
were mistaken. Instead, rely on the SnapshotAny semantics to provide
what it needs. (The business about a placeholder tuple needs to remain:
that covers the case that a transaction inserts a a tuple in a page that
summarization already scanned.)
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org
In passing, remove a couple of unused declarations from brin.h and
reword a comment to be proper English. This part submitted by Kevin
Grittner.
Backpatch to 9.5, where BRIN was introduced.
2015-08-05 21:20:50 +02:00
|
|
|
*/
|
|
|
|
if (anyvisible)
|
|
|
|
{
|
|
|
|
indexIt = true;
|
|
|
|
tupleIsAlive = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
/*
|
2010-02-07 23:40:33 +01:00
|
|
|
* Since caller should hold ShareLock or better, normally
|
|
|
|
* the only way to see this is if it was inserted earlier
|
2014-05-06 18:12:18 +02:00
|
|
|
* in our own transaction. However, it can happen in
|
2010-02-07 23:40:33 +01:00
|
|
|
* system catalogs, since we tend to release write lock
|
|
|
|
* before commit there. Give a warning if neither case
|
|
|
|
* applies.
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
*/
|
2010-02-07 23:40:33 +01:00
|
|
|
xwait = HeapTupleHeaderGetXmin(heapTuple->t_data);
|
|
|
|
if (!TransactionIdIsCurrentTransactionId(xwait))
|
2007-09-20 19:56:33 +02:00
|
|
|
{
|
2010-02-07 23:40:33 +01:00
|
|
|
if (!is_system_catalog)
|
|
|
|
elog(WARNING, "concurrent insert in progress within table \"%s\"",
|
|
|
|
RelationGetRelationName(heapRelation));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are performing uniqueness checks, indexing
|
|
|
|
* such a tuple could lead to a bogus uniqueness
|
|
|
|
* failure. In that case we wait for the inserting
|
|
|
|
* transaction to finish and check again.
|
|
|
|
*/
|
|
|
|
if (checking_uniqueness)
|
2007-09-20 19:56:33 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Must drop the lock on the buffer before we wait
|
|
|
|
*/
|
|
|
|
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_UNLOCK);
|
Setup error context callback for transaction lock waits
With this in place, a session blocking behind another one because of
tuple locks will get a context line mentioning the relation name, tuple
TID, and operation being done on tuple. For example:
LOG: process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
DETAIL: Process holding the lock: 11366. Wait queue: 11367.
CONTEXT: while updating tuple (0,2) in relation "foo"
STATEMENT: UPDATE foo SET value = 3;
Most usefully, the new line is displayed by log entries due to
log_lock_waits, although of course it will be printed by any other log
message as well.
Author: Christian Kruse, some tweaks by Álvaro Herrera
Reviewed-by: Amit Kapila, Andres Freund, Tom Lane, Robert Haas
2014-03-19 19:10:36 +01:00
|
|
|
XactLockTableWait(xwait, heapRelation,
|
2015-02-04 15:00:34 +01:00
|
|
|
&heapTuple->t_self,
|
Setup error context callback for transaction lock waits
With this in place, a session blocking behind another one because of
tuple locks will get a context line mentioning the relation name, tuple
TID, and operation being done on tuple. For example:
LOG: process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
DETAIL: Process holding the lock: 11366. Wait queue: 11367.
CONTEXT: while updating tuple (0,2) in relation "foo"
STATEMENT: UPDATE foo SET value = 3;
Most usefully, the new line is displayed by log entries due to
log_lock_waits, although of course it will be printed by any other log
message as well.
Author: Christian Kruse, some tweaks by Álvaro Herrera
Reviewed-by: Amit Kapila, Andres Freund, Tom Lane, Robert Haas
2014-03-19 19:10:36 +01:00
|
|
|
XLTW_InsertIndexUnique);
|
Fix longstanding bug in HeapTupleSatisfiesVacuum().
HeapTupleSatisfiesVacuum() didn't properly discern between
DELETE_IN_PROGRESS and INSERT_IN_PROGRESS for rows that have been
inserted in the current transaction and deleted in a aborted
subtransaction of the current backend. At the very least that caused
problems for CLUSTER and CREATE INDEX in transactions that had
aborting subtransactions producing rows, leading to warnings like:
WARNING: concurrent delete in progress within table "..."
possibly in an endless, uninterruptible, loop.
Instead of treating *InProgress xmins the same as *IsCurrent ones,
treat them as being distinct like the other visibility routines. As
implemented this separatation can cause a behaviour change for rows
that have been inserted and deleted in another, still running,
transaction. HTSV will now return INSERT_IN_PROGRESS instead of
DELETE_IN_PROGRESS for those. That's both, more in line with the other
visibility routines and arguably more correct. The latter because a
INSERT_IN_PROGRESS will make callers look at/wait for xmin, instead of
xmax.
The only current caller where that's possibly worse than the old
behaviour is heap_prune_chain() which now won't mark the page as
prunable if a row has concurrently been inserted and deleted. That's
harmless enough.
As a cautionary measure also insert a interrupt check before the gotos
in IndexBuildHeapScan() that lead to the uninterruptible loop. There
are other possible causes, like a row that several sessions try to
update and all fail, for repeated loops and the cost of doing so in
the retry case is low.
As this bug goes back all the way to the introduction of
subtransactions in 573a71a5da backpatch to all supported releases.
Reported-By: Sandro Santilli
2014-06-04 21:36:19 +02:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
2007-09-20 19:56:33 +02:00
|
|
|
goto recheck;
|
|
|
|
}
|
|
|
|
}
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-09-20 19:56:33 +02:00
|
|
|
/*
|
|
|
|
* We must index such tuples, since if the index build
|
|
|
|
* commits then they're good.
|
|
|
|
*/
|
2001-09-26 23:09:27 +02:00
|
|
|
indexIt = true;
|
|
|
|
tupleIsAlive = true;
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
break;
|
|
|
|
case HEAPTUPLE_DELETE_IN_PROGRESS:
|
2001-10-25 07:50:21 +02:00
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
/*
|
2011-04-21 02:34:11 +02:00
|
|
|
* As with INSERT_IN_PROGRESS case, this is unexpected
|
2016-01-18 01:13:18 +01:00
|
|
|
* unless it's our own deletion or a system catalog; but
|
|
|
|
* in anyvisible mode, this tuple is visible.
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
*/
|
Fix BRIN to use SnapshotAny during summarization
For correctness of summarization results, it is critical that the
snapshot used during the summarization scan is able to see all tuples
that are live to all transactions -- including tuples inserted or
deleted by in-progress transactions. Otherwise, it would be possible
for a transaction to insert a tuple, then idle for a long time while a
concurrent transaction executes summarization of the range: this would
result in the inserted value not being considered in the summary.
Previously we were trying to use a MVCC snapshot in conjunction with
adding a "placeholder" tuple in the index: the snapshot would see all
committed tuples, and the placeholder tuple would catch insertions by
any new inserters. The hole is that prior insertions by transactions
that are still in progress by the time the MVCC snapshot was taken were
ignored.
Kevin Grittner reported this as a bogus error message during vacuum with
default transaction isolation mode set to repeatable read (because the
error report mentioned a function name not being invoked during), but
the problem is larger than that.
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves
the way we need using SnapshotAny visibility rules. This change
simplifies the BRIN code a bit, mainly by removing large comments that
were mistaken. Instead, rely on the SnapshotAny semantics to provide
what it needs. (The business about a placeholder tuple needs to remain:
that covers the case that a transaction inserts a a tuple in a page that
summarization already scanned.)
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org
In passing, remove a couple of unused declarations from brin.h and
reword a comment to be proper English. This part submitted by Kevin
Grittner.
Backpatch to 9.5, where BRIN was introduced.
2015-08-05 21:20:50 +02:00
|
|
|
if (anyvisible)
|
|
|
|
{
|
|
|
|
indexIt = true;
|
|
|
|
tupleIsAlive = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
xwait = HeapTupleHeaderGetUpdateXid(heapTuple->t_data);
|
2010-02-07 23:40:33 +01:00
|
|
|
if (!TransactionIdIsCurrentTransactionId(xwait))
|
2007-09-20 19:56:33 +02:00
|
|
|
{
|
2010-02-07 23:40:33 +01:00
|
|
|
if (!is_system_catalog)
|
|
|
|
elog(WARNING, "concurrent delete in progress within table \"%s\"",
|
|
|
|
RelationGetRelationName(heapRelation));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are performing uniqueness checks, assuming
|
2010-02-26 03:01:40 +01:00
|
|
|
* the tuple is dead could lead to missing a
|
|
|
|
* uniqueness violation. In that case we wait for the
|
|
|
|
* deleting transaction to finish and check again.
|
2011-04-21 02:34:11 +02:00
|
|
|
*
|
|
|
|
* Also, if it's a HOT-updated tuple, we should not
|
|
|
|
* index it but rather the live tuple at the end of
|
|
|
|
* the HOT-chain. However, the deleting transaction
|
|
|
|
* could abort, possibly leaving this tuple as live
|
|
|
|
* after all, in which case it has to be indexed. The
|
|
|
|
* only way to know what to do is to wait for the
|
|
|
|
* deleting transaction to finish and check again.
|
2010-02-07 23:40:33 +01:00
|
|
|
*/
|
2011-04-21 02:34:11 +02:00
|
|
|
if (checking_uniqueness ||
|
|
|
|
HeapTupleIsHotUpdated(heapTuple))
|
2007-09-20 19:56:33 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Must drop the lock on the buffer before we wait
|
|
|
|
*/
|
|
|
|
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_UNLOCK);
|
Setup error context callback for transaction lock waits
With this in place, a session blocking behind another one because of
tuple locks will get a context line mentioning the relation name, tuple
TID, and operation being done on tuple. For example:
LOG: process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
DETAIL: Process holding the lock: 11366. Wait queue: 11367.
CONTEXT: while updating tuple (0,2) in relation "foo"
STATEMENT: UPDATE foo SET value = 3;
Most usefully, the new line is displayed by log entries due to
log_lock_waits, although of course it will be printed by any other log
message as well.
Author: Christian Kruse, some tweaks by Álvaro Herrera
Reviewed-by: Amit Kapila, Andres Freund, Tom Lane, Robert Haas
2014-03-19 19:10:36 +01:00
|
|
|
XactLockTableWait(xwait, heapRelation,
|
2015-02-04 15:00:34 +01:00
|
|
|
&heapTuple->t_self,
|
Setup error context callback for transaction lock waits
With this in place, a session blocking behind another one because of
tuple locks will get a context line mentioning the relation name, tuple
TID, and operation being done on tuple. For example:
LOG: process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
DETAIL: Process holding the lock: 11366. Wait queue: 11367.
CONTEXT: while updating tuple (0,2) in relation "foo"
STATEMENT: UPDATE foo SET value = 3;
Most usefully, the new line is displayed by log entries due to
log_lock_waits, although of course it will be printed by any other log
message as well.
Author: Christian Kruse, some tweaks by Álvaro Herrera
Reviewed-by: Amit Kapila, Andres Freund, Tom Lane, Robert Haas
2014-03-19 19:10:36 +01:00
|
|
|
XLTW_InsertIndexUnique);
|
Fix longstanding bug in HeapTupleSatisfiesVacuum().
HeapTupleSatisfiesVacuum() didn't properly discern between
DELETE_IN_PROGRESS and INSERT_IN_PROGRESS for rows that have been
inserted in the current transaction and deleted in a aborted
subtransaction of the current backend. At the very least that caused
problems for CLUSTER and CREATE INDEX in transactions that had
aborting subtransactions producing rows, leading to warnings like:
WARNING: concurrent delete in progress within table "..."
possibly in an endless, uninterruptible, loop.
Instead of treating *InProgress xmins the same as *IsCurrent ones,
treat them as being distinct like the other visibility routines. As
implemented this separatation can cause a behaviour change for rows
that have been inserted and deleted in another, still running,
transaction. HTSV will now return INSERT_IN_PROGRESS instead of
DELETE_IN_PROGRESS for those. That's both, more in line with the other
visibility routines and arguably more correct. The latter because a
INSERT_IN_PROGRESS will make callers look at/wait for xmin, instead of
xmax.
The only current caller where that's possibly worse than the old
behaviour is heap_prune_chain() which now won't mark the page as
prunable if a row has concurrently been inserted and deleted. That's
harmless enough.
As a cautionary measure also insert a interrupt check before the gotos
in IndexBuildHeapScan() that lead to the uninterruptible loop. There
are other possible causes, like a row that several sessions try to
update and all fail, for repeated loops and the cost of doing so in
the retry case is low.
As this bug goes back all the way to the introduction of
subtransactions in 573a71a5da backpatch to all supported releases.
Reported-By: Sandro Santilli
2014-06-04 21:36:19 +02:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
2007-09-20 19:56:33 +02:00
|
|
|
goto recheck;
|
|
|
|
}
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2011-04-21 02:34:11 +02:00
|
|
|
/*
|
|
|
|
* Otherwise index it but don't check for uniqueness,
|
|
|
|
* the same as a RECENTLY_DEAD tuple.
|
|
|
|
*/
|
|
|
|
indexIt = true;
|
|
|
|
}
|
|
|
|
else if (HeapTupleIsHotUpdated(heapTuple))
|
2007-09-20 19:56:33 +02:00
|
|
|
{
|
2011-04-21 02:34:11 +02:00
|
|
|
/*
|
|
|
|
* It's a HOT-updated tuple deleted by our own xact.
|
|
|
|
* We can assume the deletion will commit (else the
|
2011-06-09 20:32:50 +02:00
|
|
|
* index contents don't matter), so treat the same as
|
|
|
|
* RECENTLY_DEAD HOT-updated tuples.
|
2011-04-21 02:34:11 +02:00
|
|
|
*/
|
2007-09-20 19:56:33 +02:00
|
|
|
indexIt = false;
|
|
|
|
/* mark the index as unsafe for old snapshots */
|
2011-04-19 22:55:34 +02:00
|
|
|
indexInfo->ii_BrokenHotChain = true;
|
2007-09-20 19:56:33 +02:00
|
|
|
}
|
|
|
|
else
|
2011-04-21 02:34:11 +02:00
|
|
|
{
|
|
|
|
/*
|
2011-06-09 20:32:50 +02:00
|
|
|
* It's a regular tuple deleted by our own xact. Index
|
|
|
|
* it but don't check for uniqueness, the same as a
|
|
|
|
* RECENTLY_DEAD tuple.
|
2011-04-21 02:34:11 +02:00
|
|
|
*/
|
2007-09-20 19:56:33 +02:00
|
|
|
indexIt = true;
|
2011-04-21 02:34:11 +02:00
|
|
|
}
|
2007-09-20 19:56:33 +02:00
|
|
|
/* In any case, exclude the tuple from unique-checking */
|
2001-09-26 23:09:27 +02:00
|
|
|
tupleIsAlive = false;
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
break;
|
|
|
|
default:
|
2003-07-21 03:59:11 +02:00
|
|
|
elog(ERROR, "unexpected HeapTupleSatisfiesVacuum result");
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
indexIt = tupleIsAlive = false; /* keep compiler quiet */
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
|
|
|
|
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_UNLOCK);
|
|
|
|
|
2001-10-25 07:50:21 +02:00
|
|
|
if (!indexIt)
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
continue;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/* heap_getnext did the time qual check */
|
|
|
|
tupleIsAlive = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
reltuples += 1;
|
|
|
|
|
|
|
|
MemoryContextReset(econtext->ecxt_per_tuple_memory);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-05-29 02:54:42 +02:00
|
|
|
/* Set up for predicate or expression evaluation */
|
2005-03-16 22:38:10 +01:00
|
|
|
ExecStoreTuple(heapTuple, slot, InvalidBuffer, false);
|
2003-05-29 02:54:42 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
* In a partial index, discard tuples that don't satisfy the
|
2006-03-25 00:02:17 +01:00
|
|
|
* predicate.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (predicate != NULL)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (!ExecQual(predicate, econtext))
|
1997-09-07 07:04:48 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* For the current heap tuple, extract all the attributes we use in
|
|
|
|
* this index, and note which are null. This also performs evaluation
|
|
|
|
* of any expressions needed.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-07-15 00:18:02 +02:00
|
|
|
FormIndexDatum(indexInfo,
|
2005-03-16 22:38:10 +01:00
|
|
|
slot,
|
2003-05-28 18:04:02 +02:00
|
|
|
estate,
|
2005-03-21 02:24:04 +01:00
|
|
|
values,
|
|
|
|
isnull);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* You'd think we should go ahead and build the index tuple here, but
|
2014-05-06 18:12:18 +02:00
|
|
|
* some index AMs want to do further processing on the data first. So
|
2005-10-15 04:49:52 +02:00
|
|
|
* pass the values[] and isnull[] arrays, instead.
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2007-09-20 19:56:33 +02:00
|
|
|
if (HeapTupleIsHeapOnly(heapTuple))
|
|
|
|
{
|
|
|
|
/*
|
2007-11-15 22:14:46 +01:00
|
|
|
* For a heap-only tuple, pretend its TID is that of the root. See
|
|
|
|
* src/backend/access/heap/README.HOT for discussion.
|
2007-09-20 19:56:33 +02:00
|
|
|
*/
|
2007-11-15 22:14:46 +01:00
|
|
|
HeapTupleData rootTuple;
|
|
|
|
OffsetNumber offnum;
|
2007-09-20 19:56:33 +02:00
|
|
|
|
|
|
|
rootTuple = *heapTuple;
|
|
|
|
offnum = ItemPointerGetOffsetNumber(&heapTuple->t_self);
|
|
|
|
|
2014-03-17 17:36:11 +01:00
|
|
|
if (!OffsetNumberIsValid(root_offsets[offnum - 1]))
|
|
|
|
elog(ERROR, "failed to find parent tuple for heap-only tuple at (%u,%u) in table \"%s\"",
|
|
|
|
ItemPointerGetBlockNumber(&heapTuple->t_self),
|
|
|
|
offnum, RelationGetRelationName(heapRelation));
|
2007-09-20 19:56:33 +02:00
|
|
|
|
|
|
|
ItemPointerSetOffsetNumber(&rootTuple.t_self,
|
|
|
|
root_offsets[offnum - 1]);
|
|
|
|
|
|
|
|
/* Call the AM's callback routine to process the tuple */
|
|
|
|
callback(indexRelation, &rootTuple, values, isnull, tupleIsAlive,
|
|
|
|
callback_state);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Call the AM's callback routine to process the tuple */
|
|
|
|
callback(indexRelation, heapTuple, values, isnull, tupleIsAlive,
|
|
|
|
callback_state);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
heap_endscan(scan);
|
|
|
|
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
/* we can now forget our snapshot, if set and registered by us */
|
|
|
|
if (need_unregister_snapshot)
|
2008-05-12 22:02:02 +02:00
|
|
|
UnregisterSnapshot(snapshot);
|
|
|
|
|
2005-03-16 22:38:10 +01:00
|
|
|
ExecDropSingleTupleTableSlot(slot);
|
2002-12-15 17:17:59 +01:00
|
|
|
|
|
|
|
FreeExecutorState(estate);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-05-28 18:04:02 +02:00
|
|
|
/* These may have been pointing to the now-gone estate */
|
|
|
|
indexInfo->ii_ExpressionsState = NIL;
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
indexInfo->ii_PredicateState = NULL;
|
2003-05-28 18:04:02 +02:00
|
|
|
|
Restructure index AM interface for index building and index tuple deletion,
per previous discussion on pghackers. Most of the duplicate code in
different AMs' ambuild routines has been moved out to a common routine
in index.c; this means that all index types now do the right things about
inserting recently-dead tuples, etc. (I also removed support for EXTEND
INDEX in the ambuild routines, since that's about to go away anyway, and
it cluttered the code a lot.) The retail indextuple deletion routines have
been replaced by a "bulk delete" routine in which the indexscan is inside
the access method. I haven't pushed this change as far as it should go yet,
but it should allow considerable simplification of the internal bookkeeping
for deletions. Also, add flag columns to pg_am to eliminate various
hardcoded tests on AM OIDs, and remove unused pg_am columns.
Fix rtree and gist index types to not attempt to store NULLs; before this,
gist usually crashed, while rtree managed not to crash but computed wacko
bounding boxes for NULL entries (which might have had something to do with
the performance problems we've heard about occasionally).
Add AtEOXact routines to hash, rtree, and gist, all of which have static
state that needs to be reset after an error. We discovered this need long
ago for btree, but missed the other guys.
Oh, one more thing: concurrent VACUUM is now the default.
2001-07-16 00:48:19 +02:00
|
|
|
return reltuples;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
/*
|
|
|
|
* IndexCheckExclusion - verify that a new exclusion constraint is satisfied
|
|
|
|
*
|
|
|
|
* When creating an exclusion constraint, we first build the index normally
|
|
|
|
* and then rescan the heap to check for conflicts. We assume that we only
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
* need to validate tuples that are live according to an up-to-date snapshot,
|
|
|
|
* and that these were correctly indexed even in the presence of broken HOT
|
|
|
|
* chains. This should be OK since we are holding at least ShareLock on the
|
|
|
|
* table, meaning there can be no uncommitted updates from other transactions.
|
2009-12-07 06:22:23 +01:00
|
|
|
* (Note: that wouldn't necessarily work for system catalogs, since many
|
|
|
|
* operations release write lock early on the system catalogs.)
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
IndexCheckExclusion(Relation heapRelation,
|
|
|
|
Relation indexRelation,
|
|
|
|
IndexInfo *indexInfo)
|
|
|
|
{
|
|
|
|
HeapScanDesc scan;
|
|
|
|
HeapTuple heapTuple;
|
|
|
|
Datum values[INDEX_MAX_KEYS];
|
|
|
|
bool isnull[INDEX_MAX_KEYS];
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExprState *predicate;
|
2009-12-07 06:22:23 +01:00
|
|
|
TupleTableSlot *slot;
|
|
|
|
EState *estate;
|
|
|
|
ExprContext *econtext;
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
Snapshot snapshot;
|
2009-12-07 06:22:23 +01:00
|
|
|
|
2011-06-06 04:30:04 +02:00
|
|
|
/*
|
|
|
|
* If we are reindexing the target index, mark it as no longer being
|
2011-06-09 20:32:50 +02:00
|
|
|
* reindexed, to forestall an Assert in index_beginscan when we try to use
|
|
|
|
* the index for probes. This is OK because the index is now fully valid.
|
2011-06-06 04:30:04 +02:00
|
|
|
*/
|
|
|
|
if (ReindexIsCurrentlyProcessingIndex(RelationGetRelid(indexRelation)))
|
|
|
|
ResetReindexProcessing();
|
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
/*
|
|
|
|
* Need an EState for evaluation of index expressions and partial-index
|
2014-05-06 18:12:18 +02:00
|
|
|
* predicates. Also a slot to hold the current tuple.
|
2009-12-07 06:22:23 +01:00
|
|
|
*/
|
|
|
|
estate = CreateExecutorState();
|
|
|
|
econtext = GetPerTupleExprContext(estate);
|
|
|
|
slot = MakeSingleTupleTableSlot(RelationGetDescr(heapRelation));
|
|
|
|
|
|
|
|
/* Arrange for econtext's scan tuple to be the tuple under test */
|
|
|
|
econtext->ecxt_scantuple = slot;
|
|
|
|
|
|
|
|
/* Set up execution state for predicate, if any. */
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
predicate = ExecPrepareQual(indexInfo->ii_Predicate, estate);
|
2009-12-07 06:22:23 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan all live tuples in the base relation.
|
|
|
|
*/
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
snapshot = RegisterSnapshot(GetLatestSnapshot());
|
2009-12-07 06:22:23 +01:00
|
|
|
scan = heap_beginscan_strat(heapRelation, /* relation */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
snapshot, /* snapshot */
|
|
|
|
0, /* number of keys */
|
2009-12-07 06:22:23 +01:00
|
|
|
NULL, /* scan key */
|
|
|
|
true, /* buffer access strategy OK */
|
|
|
|
true); /* syncscan OK */
|
|
|
|
|
|
|
|
while ((heapTuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
|
|
|
|
{
|
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
|
|
|
MemoryContextReset(econtext->ecxt_per_tuple_memory);
|
|
|
|
|
|
|
|
/* Set up for predicate or expression evaluation */
|
|
|
|
ExecStoreTuple(heapTuple, slot, InvalidBuffer, false);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In a partial index, ignore tuples that don't satisfy the predicate.
|
|
|
|
*/
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (predicate != NULL)
|
2009-12-07 06:22:23 +01:00
|
|
|
{
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (!ExecQual(predicate, econtext))
|
2009-12-07 06:22:23 +01:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Extract index column values, including computing expressions.
|
|
|
|
*/
|
|
|
|
FormIndexDatum(indexInfo,
|
|
|
|
slot,
|
|
|
|
estate,
|
|
|
|
values,
|
|
|
|
isnull);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check that this tuple has no conflicts.
|
|
|
|
*/
|
|
|
|
check_exclusion_constraint(heapRelation,
|
|
|
|
indexRelation, indexInfo,
|
|
|
|
&(heapTuple->t_self), values, isnull,
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
estate, true);
|
2009-12-07 06:22:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
heap_endscan(scan);
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
UnregisterSnapshot(snapshot);
|
2009-12-07 06:22:23 +01:00
|
|
|
|
|
|
|
ExecDropSingleTupleTableSlot(slot);
|
|
|
|
|
|
|
|
FreeExecutorState(estate);
|
|
|
|
|
|
|
|
/* These may have been pointing to the now-gone estate */
|
|
|
|
indexInfo->ii_ExpressionsState = NIL;
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
indexInfo->ii_PredicateState = NULL;
|
2009-12-07 06:22:23 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
/*
|
|
|
|
* validate_index - support code for concurrent index builds
|
|
|
|
*
|
2007-09-20 19:56:33 +02:00
|
|
|
* We do a concurrent index build by first inserting the catalog entry for the
|
|
|
|
* index via index_create(), marking it not indisready and not indisvalid.
|
|
|
|
* Then we commit our transaction and start a new one, then we wait for all
|
2014-05-06 18:12:18 +02:00
|
|
|
* transactions that could have been modifying the table to terminate. Now
|
2007-09-20 19:56:33 +02:00
|
|
|
* we know that any subsequently-started transactions will see the index and
|
|
|
|
* honor its constraints on HOT updates; so while existing HOT-chains might
|
|
|
|
* be broken with respect to the index, no currently live tuple will have an
|
2014-05-06 18:12:18 +02:00
|
|
|
* incompatible HOT update done to it. We now build the index normally via
|
2007-09-20 19:56:33 +02:00
|
|
|
* index_build(), while holding a weak lock that allows concurrent
|
2006-08-25 06:06:58 +02:00
|
|
|
* insert/update/delete. Also, we index only tuples that are valid
|
|
|
|
* as of the start of the scan (see IndexBuildHeapScan), whereas a normal
|
|
|
|
* build takes care to include recently-dead tuples. This is OK because
|
|
|
|
* we won't mark the index valid until all transactions that might be able
|
|
|
|
* to see those tuples are gone. The reason for doing that is to avoid
|
|
|
|
* bogus unique-index failures due to concurrent UPDATEs (we might see
|
|
|
|
* different versions of the same row as being valid when we pass over them,
|
|
|
|
* if we used HeapTupleSatisfiesVacuum). This leaves us with an index that
|
|
|
|
* does not contain any tuples added to the table while we built the index.
|
|
|
|
*
|
2007-09-20 19:56:33 +02:00
|
|
|
* Next, we mark the index "indisready" (but still not "indisvalid") and
|
|
|
|
* commit the second transaction and start a third. Again we wait for all
|
2014-05-06 18:12:18 +02:00
|
|
|
* transactions that could have been modifying the table to terminate. Now
|
2007-09-20 19:56:33 +02:00
|
|
|
* we know that any subsequently-started transactions will see the index and
|
2006-08-25 06:06:58 +02:00
|
|
|
* insert their new tuples into it. We then take a new reference snapshot
|
|
|
|
* which is passed to validate_index(). Any tuples that are valid according
|
|
|
|
* to this snap, but are not in the index, must be added to the index.
|
|
|
|
* (Any tuples committed live after the snap will be inserted into the
|
2014-05-06 18:12:18 +02:00
|
|
|
* index by their originating transaction. Any tuples committed dead before
|
2006-08-25 06:06:58 +02:00
|
|
|
* the snap need not be indexed, because we will wait out all transactions
|
|
|
|
* that might care about them before we mark the index valid.)
|
|
|
|
*
|
|
|
|
* validate_index() works by first gathering all the TIDs currently in the
|
|
|
|
* index, using a bulkdelete callback that just stores the TIDs and doesn't
|
|
|
|
* ever say "delete it". (This should be faster than a plain indexscan;
|
|
|
|
* also, not all index AMs support full-index indexscan.) Then we sort the
|
|
|
|
* TIDs, and finally scan the table doing a "merge join" against the TID list
|
2014-05-06 18:12:18 +02:00
|
|
|
* to see which tuples are missing from the index. Thus we will ensure that
|
2006-08-25 06:06:58 +02:00
|
|
|
* all tuples valid according to the reference snapshot are in the index.
|
|
|
|
*
|
|
|
|
* Building a unique index this way is tricky: we might try to insert a
|
|
|
|
* tuple that is already dead or is in process of being deleted, and we
|
|
|
|
* mustn't have a uniqueness failure against an updated version of the same
|
2007-09-20 19:56:33 +02:00
|
|
|
* row. We could try to check the tuple to see if it's already dead and tell
|
2006-08-25 06:06:58 +02:00
|
|
|
* index_insert() not to do the uniqueness check, but that still leaves us
|
|
|
|
* with a race condition against an in-progress update. To handle that,
|
|
|
|
* we expect the index AM to recheck liveness of the to-be-inserted tuple
|
|
|
|
* before it declares a uniqueness error.
|
|
|
|
*
|
|
|
|
* After completing validate_index(), we wait until all transactions that
|
|
|
|
* were alive at the time of the reference snapshot are gone; this is
|
2010-09-11 20:38:58 +02:00
|
|
|
* necessary to be sure there are none left with a transaction snapshot
|
2006-08-25 06:06:58 +02:00
|
|
|
* older than the reference (and hence possibly able to see tuples we did
|
2014-05-06 18:12:18 +02:00
|
|
|
* not index). Then we mark the index "indisvalid" and commit. Subsequent
|
2007-09-20 19:56:33 +02:00
|
|
|
* transactions will be able to use it for queries.
|
2006-08-25 06:06:58 +02:00
|
|
|
*
|
|
|
|
* Doing two full table scans is a brute-force strategy. We could try to be
|
|
|
|
* cleverer, eg storing new tuples in a special area of the table (perhaps
|
|
|
|
* making the table append-only by setting use_fsm). However that would
|
|
|
|
* add yet more locking issues.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
validate_index(Oid heapId, Oid indexId, Snapshot snapshot)
|
|
|
|
{
|
2006-10-04 02:30:14 +02:00
|
|
|
Relation heapRelation,
|
|
|
|
indexRelation;
|
|
|
|
IndexInfo *indexInfo;
|
2006-08-25 06:06:58 +02:00
|
|
|
IndexVacuumInfo ivinfo;
|
2006-10-04 02:30:14 +02:00
|
|
|
v_i_state state;
|
2008-01-03 22:23:15 +01:00
|
|
|
Oid save_userid;
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
int save_sec_context;
|
|
|
|
int save_nestlevel;
|
2006-08-25 06:06:58 +02:00
|
|
|
|
|
|
|
/* Open and lock the parent heap relation */
|
|
|
|
heapRelation = heap_open(heapId, ShareUpdateExclusiveLock);
|
|
|
|
/* And the target index relation */
|
|
|
|
indexRelation = index_open(indexId, RowExclusiveLock);
|
|
|
|
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Fetch info needed for index_insert. (You might think this should be
|
2006-10-04 02:30:14 +02:00
|
|
|
* passed in from DefineIndex, but its copy is long gone due to having
|
|
|
|
* been built in a previous transaction.)
|
2006-08-25 06:06:58 +02:00
|
|
|
*/
|
|
|
|
indexInfo = BuildIndexInfo(indexRelation);
|
|
|
|
|
|
|
|
/* mark build is concurrent just for consistency */
|
|
|
|
indexInfo->ii_Concurrent = true;
|
|
|
|
|
2008-01-03 22:23:15 +01:00
|
|
|
/*
|
2009-06-11 16:49:15 +02:00
|
|
|
* Switch to the table owner's userid, so that any index functions are run
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
* as that user. Also lock down security-restricted operations and
|
|
|
|
* arrange to make GUC variable changes local to this command.
|
2008-01-03 22:23:15 +01:00
|
|
|
*/
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
GetUserIdAndSecContext(&save_userid, &save_sec_context);
|
|
|
|
SetUserIdAndSecContext(heapRelation->rd_rel->relowner,
|
|
|
|
save_sec_context | SECURITY_RESTRICTED_OPERATION);
|
|
|
|
save_nestlevel = NewGUCNestLevel();
|
2008-01-03 22:23:15 +01:00
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
/*
|
|
|
|
* Scan the index and gather up all the TIDs into a tuplesort object.
|
|
|
|
*/
|
|
|
|
ivinfo.index = indexRelation;
|
2009-03-24 21:17:18 +01:00
|
|
|
ivinfo.analyze_only = false;
|
2009-06-07 00:13:52 +02:00
|
|
|
ivinfo.estimated_count = true;
|
2006-08-25 06:06:58 +02:00
|
|
|
ivinfo.message_level = DEBUG2;
|
2009-06-07 00:13:52 +02:00
|
|
|
ivinfo.num_heap_tuples = heapRelation->rd_rel->reltuples;
|
2007-05-30 22:12:03 +02:00
|
|
|
ivinfo.strategy = NULL;
|
2006-08-25 06:06:58 +02:00
|
|
|
|
2015-12-16 21:23:45 +01:00
|
|
|
/*
|
|
|
|
* Encode TIDs as int8 values for the sort, rather than directly sorting
|
|
|
|
* item pointers. This can be significantly faster, primarily because TID
|
|
|
|
* is a pass-by-reference type on all platforms, whereas int8 is
|
|
|
|
* pass-by-value on most platforms.
|
|
|
|
*/
|
|
|
|
state.tuplesort = tuplesort_begin_datum(INT8OID, Int8LessOperator,
|
2011-04-22 23:43:18 +02:00
|
|
|
InvalidOid, false,
|
2006-08-25 06:06:58 +02:00
|
|
|
maintenance_work_mem,
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
NULL, false);
|
2006-08-25 06:06:58 +02:00
|
|
|
state.htups = state.itups = state.tups_inserted = 0;
|
|
|
|
|
|
|
|
(void) index_bulk_delete(&ivinfo, NULL,
|
|
|
|
validate_index_callback, (void *) &state);
|
|
|
|
|
|
|
|
/* Execute the sort */
|
|
|
|
tuplesort_performsort(state.tuplesort);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now scan the heap and "merge" it with the index
|
|
|
|
*/
|
|
|
|
validate_index_heapscan(heapRelation,
|
|
|
|
indexRelation,
|
|
|
|
indexInfo,
|
|
|
|
snapshot,
|
|
|
|
&state);
|
|
|
|
|
|
|
|
/* Done with tuplesort object */
|
|
|
|
tuplesort_end(state.tuplesort);
|
|
|
|
|
|
|
|
elog(DEBUG2,
|
|
|
|
"validate_index found %.0f heap tuples, %.0f index tuples; inserted %.0f missing tuples",
|
|
|
|
state.htups, state.itups, state.tups_inserted);
|
|
|
|
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
/* Roll back any GUC changes executed by index functions */
|
|
|
|
AtEOXact_GUC(false, save_nestlevel);
|
|
|
|
|
|
|
|
/* Restore userid and security context */
|
|
|
|
SetUserIdAndSecContext(save_userid, save_sec_context);
|
2008-01-03 22:23:15 +01:00
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
/* Close rels, but keep locks */
|
|
|
|
index_close(indexRelation, NoLock);
|
|
|
|
heap_close(heapRelation, NoLock);
|
|
|
|
}
|
|
|
|
|
2015-12-16 21:23:45 +01:00
|
|
|
/*
|
|
|
|
* itemptr_encode - Encode ItemPointer as int64/int8
|
|
|
|
*
|
|
|
|
* This representation must produce values encoded as int64 that sort in the
|
|
|
|
* same order as their corresponding original TID values would (using the
|
|
|
|
* default int8 opclass to produce a result equivalent to the default TID
|
|
|
|
* opclass).
|
|
|
|
*
|
|
|
|
* As noted in validate_index(), this can be significantly faster.
|
|
|
|
*/
|
|
|
|
static inline int64
|
|
|
|
itemptr_encode(ItemPointer itemptr)
|
|
|
|
{
|
2016-01-18 01:13:18 +01:00
|
|
|
BlockNumber block = ItemPointerGetBlockNumber(itemptr);
|
|
|
|
OffsetNumber offset = ItemPointerGetOffsetNumber(itemptr);
|
|
|
|
int64 encoded;
|
2015-12-16 21:23:45 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Use the 16 least significant bits for the offset. 32 adjacent bits are
|
|
|
|
* used for the block number. Since remaining bits are unused, there
|
|
|
|
* cannot be negative encoded values (We assume a two's complement
|
|
|
|
* representation).
|
|
|
|
*/
|
|
|
|
encoded = ((uint64) block << 16) | (uint16) offset;
|
|
|
|
|
|
|
|
return encoded;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* itemptr_decode - Decode int64/int8 representation back to ItemPointer
|
|
|
|
*/
|
|
|
|
static inline void
|
|
|
|
itemptr_decode(ItemPointer itemptr, int64 encoded)
|
|
|
|
{
|
2016-01-18 01:13:18 +01:00
|
|
|
BlockNumber block = (BlockNumber) (encoded >> 16);
|
|
|
|
OffsetNumber offset = (OffsetNumber) (encoded & 0xFFFF);
|
2015-12-16 21:23:45 +01:00
|
|
|
|
|
|
|
ItemPointerSet(itemptr, block, offset);
|
|
|
|
}
|
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
/*
|
|
|
|
* validate_index_callback - bulkdelete callback to collect the index TIDs
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
validate_index_callback(ItemPointer itemptr, void *opaque)
|
|
|
|
{
|
2006-10-04 02:30:14 +02:00
|
|
|
v_i_state *state = (v_i_state *) opaque;
|
2015-12-16 21:23:45 +01:00
|
|
|
int64 encoded = itemptr_encode(itemptr);
|
2006-08-25 06:06:58 +02:00
|
|
|
|
2015-12-16 21:23:45 +01:00
|
|
|
tuplesort_putdatum(state->tuplesort, Int64GetDatum(encoded), false);
|
2006-08-25 06:06:58 +02:00
|
|
|
state->itups += 1;
|
|
|
|
return false; /* never actually delete anything */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* validate_index_heapscan - second table scan for concurrent index build
|
|
|
|
*
|
|
|
|
* This has much code in common with IndexBuildHeapScan, but it's enough
|
|
|
|
* different that it seems cleaner to have two routines not one.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
validate_index_heapscan(Relation heapRelation,
|
|
|
|
Relation indexRelation,
|
|
|
|
IndexInfo *indexInfo,
|
|
|
|
Snapshot snapshot,
|
|
|
|
v_i_state *state)
|
|
|
|
{
|
|
|
|
HeapScanDesc scan;
|
|
|
|
HeapTuple heapTuple;
|
|
|
|
Datum values[INDEX_MAX_KEYS];
|
|
|
|
bool isnull[INDEX_MAX_KEYS];
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
ExprState *predicate;
|
2006-08-25 06:06:58 +02:00
|
|
|
TupleTableSlot *slot;
|
|
|
|
EState *estate;
|
|
|
|
ExprContext *econtext;
|
2007-09-20 19:56:33 +02:00
|
|
|
BlockNumber root_blkno = InvalidBlockNumber;
|
2007-11-15 22:14:46 +01:00
|
|
|
OffsetNumber root_offsets[MaxHeapTuplesPerPage];
|
|
|
|
bool in_index[MaxHeapTuplesPerPage];
|
2006-10-04 02:30:14 +02:00
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
/* state variables for the merge */
|
|
|
|
ItemPointer indexcursor = NULL;
|
2016-01-18 01:13:18 +01:00
|
|
|
ItemPointerData decoded;
|
2006-10-04 02:30:14 +02:00
|
|
|
bool tuplesort_empty = false;
|
2006-08-25 06:06:58 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* sanity checks
|
|
|
|
*/
|
|
|
|
Assert(OidIsValid(indexRelation->rd_rel->relam));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Need an EState for evaluation of index expressions and partial-index
|
2014-05-06 18:12:18 +02:00
|
|
|
* predicates. Also a slot to hold the current tuple.
|
2006-08-25 06:06:58 +02:00
|
|
|
*/
|
|
|
|
estate = CreateExecutorState();
|
|
|
|
econtext = GetPerTupleExprContext(estate);
|
|
|
|
slot = MakeSingleTupleTableSlot(RelationGetDescr(heapRelation));
|
|
|
|
|
|
|
|
/* Arrange for econtext's scan tuple to be the tuple under test */
|
|
|
|
econtext->ecxt_scantuple = slot;
|
|
|
|
|
|
|
|
/* Set up execution state for predicate, if any. */
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
predicate = ExecPrepareQual(indexInfo->ii_Predicate, estate);
|
2006-08-25 06:06:58 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepare for scan of the base relation. We need just those tuples
|
2008-01-14 02:39:09 +01:00
|
|
|
* satisfying the passed-in reference snapshot. We must disable syncscan
|
|
|
|
* here, because it's critical that we read from block zero forward to
|
|
|
|
* match the sorted TIDs.
|
2006-08-25 06:06:58 +02:00
|
|
|
*/
|
2008-01-14 02:39:09 +01:00
|
|
|
scan = heap_beginscan_strat(heapRelation, /* relation */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
snapshot, /* snapshot */
|
|
|
|
0, /* number of keys */
|
2009-06-11 16:49:15 +02:00
|
|
|
NULL, /* scan key */
|
|
|
|
true, /* buffer access strategy OK */
|
|
|
|
false); /* syncscan not OK */
|
2006-08-25 06:06:58 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan all tuples matching the snapshot.
|
|
|
|
*/
|
|
|
|
while ((heapTuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
|
|
|
|
{
|
|
|
|
ItemPointer heapcursor = &heapTuple->t_self;
|
2007-09-20 19:56:33 +02:00
|
|
|
ItemPointerData rootTuple;
|
2007-11-15 22:14:46 +01:00
|
|
|
OffsetNumber root_offnum;
|
2006-08-25 06:06:58 +02:00
|
|
|
|
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
|
|
|
state->htups += 1;
|
|
|
|
|
2007-09-20 19:56:33 +02:00
|
|
|
/*
|
2007-11-15 22:14:46 +01:00
|
|
|
* As commented in IndexBuildHeapScan, we should index heap-only
|
|
|
|
* tuples under the TIDs of their root tuples; so when we advance onto
|
|
|
|
* a new heap page, build a map of root item offsets on the page.
|
2007-09-20 19:56:33 +02:00
|
|
|
*
|
|
|
|
* This complicates merging against the tuplesort output: we will
|
|
|
|
* visit the live tuples in order by their offsets, but the root
|
2007-11-15 22:14:46 +01:00
|
|
|
* offsets that we need to compare against the index contents might be
|
|
|
|
* ordered differently. So we might have to "look back" within the
|
2014-05-06 18:12:18 +02:00
|
|
|
* tuplesort output, but only within the current page. We handle that
|
2007-11-15 22:14:46 +01:00
|
|
|
* by keeping a bool array in_index[] showing all the
|
|
|
|
* already-passed-over tuplesort output TIDs of the current page. We
|
|
|
|
* clear that array here, when advancing onto a new heap page.
|
2007-09-20 19:56:33 +02:00
|
|
|
*/
|
|
|
|
if (scan->rs_cblock != root_blkno)
|
|
|
|
{
|
2016-04-20 15:31:19 +02:00
|
|
|
Page page = BufferGetPage(scan->rs_cbuf);
|
2007-09-20 19:56:33 +02:00
|
|
|
|
|
|
|
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_SHARE);
|
|
|
|
heap_get_root_tuples(page, root_offsets);
|
|
|
|
LockBuffer(scan->rs_cbuf, BUFFER_LOCK_UNLOCK);
|
|
|
|
|
|
|
|
memset(in_index, 0, sizeof(in_index));
|
|
|
|
|
|
|
|
root_blkno = scan->rs_cblock;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Convert actual tuple TID to root TID */
|
|
|
|
rootTuple = *heapcursor;
|
|
|
|
root_offnum = ItemPointerGetOffsetNumber(heapcursor);
|
|
|
|
|
|
|
|
if (HeapTupleIsHeapOnly(heapTuple))
|
|
|
|
{
|
|
|
|
root_offnum = root_offsets[root_offnum - 1];
|
2014-03-17 17:36:11 +01:00
|
|
|
if (!OffsetNumberIsValid(root_offnum))
|
|
|
|
elog(ERROR, "failed to find parent tuple for heap-only tuple at (%u,%u) in table \"%s\"",
|
|
|
|
ItemPointerGetBlockNumber(heapcursor),
|
|
|
|
ItemPointerGetOffsetNumber(heapcursor),
|
|
|
|
RelationGetRelationName(heapRelation));
|
2007-09-20 19:56:33 +02:00
|
|
|
ItemPointerSetOffsetNumber(&rootTuple, root_offnum);
|
|
|
|
}
|
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* "merge" by skipping through the index tuples until we find or pass
|
2007-09-20 19:56:33 +02:00
|
|
|
* the current root tuple.
|
2006-08-25 06:06:58 +02:00
|
|
|
*/
|
|
|
|
while (!tuplesort_empty &&
|
|
|
|
(!indexcursor ||
|
2007-09-20 19:56:33 +02:00
|
|
|
ItemPointerCompare(indexcursor, &rootTuple) < 0))
|
2006-08-25 06:06:58 +02:00
|
|
|
{
|
2006-10-04 02:30:14 +02:00
|
|
|
Datum ts_val;
|
|
|
|
bool ts_isnull;
|
2006-08-25 06:06:58 +02:00
|
|
|
|
|
|
|
if (indexcursor)
|
2007-09-20 19:56:33 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Remember index items seen earlier on the current heap page
|
|
|
|
*/
|
|
|
|
if (ItemPointerGetBlockNumber(indexcursor) == root_blkno)
|
|
|
|
in_index[ItemPointerGetOffsetNumber(indexcursor) - 1] = true;
|
|
|
|
}
|
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
tuplesort_empty = !tuplesort_getdatum(state->tuplesort, true,
|
2016-02-17 11:10:00 +01:00
|
|
|
&ts_val, &ts_isnull, NULL);
|
2006-08-25 06:06:58 +02:00
|
|
|
Assert(tuplesort_empty || !ts_isnull);
|
2015-12-16 21:23:45 +01:00
|
|
|
if (!tuplesort_empty)
|
|
|
|
{
|
|
|
|
itemptr_decode(&decoded, DatumGetInt64(ts_val));
|
|
|
|
indexcursor = &decoded;
|
|
|
|
|
|
|
|
/* If int8 is pass-by-ref, free (encoded) TID Datum memory */
|
|
|
|
#ifndef USE_FLOAT8_BYVAL
|
|
|
|
pfree(DatumGetPointer(ts_val));
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Be tidy */
|
|
|
|
indexcursor = NULL;
|
|
|
|
}
|
2006-08-25 06:06:58 +02:00
|
|
|
}
|
|
|
|
|
2007-09-20 19:56:33 +02:00
|
|
|
/*
|
|
|
|
* If the tuplesort has overshot *and* we didn't see a match earlier,
|
|
|
|
* then this tuple is missing from the index, so insert it.
|
|
|
|
*/
|
|
|
|
if ((tuplesort_empty ||
|
|
|
|
ItemPointerCompare(indexcursor, &rootTuple) > 0) &&
|
|
|
|
!in_index[root_offnum - 1])
|
2006-08-25 06:06:58 +02:00
|
|
|
{
|
|
|
|
MemoryContextReset(econtext->ecxt_per_tuple_memory);
|
|
|
|
|
|
|
|
/* Set up for predicate or expression evaluation */
|
|
|
|
ExecStoreTuple(heapTuple, slot, InvalidBuffer, false);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In a partial index, discard tuples that don't satisfy the
|
|
|
|
* predicate.
|
|
|
|
*/
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (predicate != NULL)
|
2006-08-25 06:06:58 +02:00
|
|
|
{
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
if (!ExecQual(predicate, econtext))
|
2006-08-25 06:06:58 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For the current heap tuple, extract all the attributes we use
|
2014-05-06 18:12:18 +02:00
|
|
|
* in this index, and note which are null. This also performs
|
2006-08-25 06:06:58 +02:00
|
|
|
* evaluation of any expressions needed.
|
|
|
|
*/
|
|
|
|
FormIndexDatum(indexInfo,
|
|
|
|
slot,
|
|
|
|
estate,
|
|
|
|
values,
|
|
|
|
isnull);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* You'd think we should go ahead and build the index tuple here,
|
|
|
|
* but some index AMs want to do further processing on the data
|
|
|
|
* first. So pass the values[] and isnull[] arrays, instead.
|
|
|
|
*/
|
2007-09-20 19:56:33 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the tuple is already committed dead, you might think we
|
2007-11-15 22:14:46 +01:00
|
|
|
* could suppress uniqueness checking, but this is no longer true
|
|
|
|
* in the presence of HOT, because the insert is actually a proxy
|
|
|
|
* for a uniqueness check on the whole HOT-chain. That is, the
|
|
|
|
* tuple we have here could be dead because it was already
|
2007-09-20 19:56:33 +02:00
|
|
|
* HOT-updated, and if so the updating transaction will not have
|
2014-05-06 18:12:18 +02:00
|
|
|
* thought it should insert index entries. The index AM will
|
2007-11-15 22:14:46 +01:00
|
|
|
* check the whole HOT-chain and correctly detect a conflict if
|
|
|
|
* there is one.
|
2007-09-20 19:56:33 +02:00
|
|
|
*/
|
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
index_insert(indexRelation,
|
|
|
|
values,
|
|
|
|
isnull,
|
2007-09-20 19:56:33 +02:00
|
|
|
&rootTuple,
|
2006-08-25 06:06:58 +02:00
|
|
|
heapRelation,
|
2009-07-29 22:56:21 +02:00
|
|
|
indexInfo->ii_Unique ?
|
Allow index AMs to cache data across aminsert calls within a SQL command.
It's always been possible for index AMs to cache data across successive
amgettuple calls within a single SQL command: the IndexScanDesc.opaque
field is meant for precisely that. However, no comparable facility
exists for amortizing setup work across successive aminsert calls.
This patch adds such a feature and teaches GIN, GIST, and BRIN to use it
to amortize catalog lookups they'd previously been doing on every call.
(The other standard index AMs keep everything they need in the relcache,
so there's little to improve there.)
For GIN, the overall improvement in a statement that inserts many rows
can be as much as 10%, though it seems a bit less for the other two.
In addition, this makes a really significant difference in runtime
for CLOBBER_CACHE_ALWAYS tests, since in those builds the repeated
catalog lookups are vastly more expensive.
The reason this has been hard up to now is that the aminsert function is
not passed any useful place to cache per-statement data. What I chose to
do is to add suitable fields to struct IndexInfo and pass that to aminsert.
That's not widening the index AM API very much because IndexInfo is already
within the ken of ambuild; in fact, by passing the same info to aminsert
as to ambuild, this is really removing an inconsistency in the AM API.
Discussion: https://postgr.es/m/27568.1486508680@sss.pgh.pa.us
2017-02-09 17:52:12 +01:00
|
|
|
UNIQUE_CHECK_YES : UNIQUE_CHECK_NO,
|
|
|
|
indexInfo);
|
2006-08-25 06:06:58 +02:00
|
|
|
|
|
|
|
state->tups_inserted += 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
heap_endscan(scan);
|
|
|
|
|
|
|
|
ExecDropSingleTupleTableSlot(slot);
|
|
|
|
|
|
|
|
FreeExecutorState(estate);
|
|
|
|
|
|
|
|
/* These may have been pointing to the now-gone estate */
|
|
|
|
indexInfo->ii_ExpressionsState = NIL;
|
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, with
non-recursive, opcode dispatch based, expression evaluation.
Projection is now implemented as part of expression evaluation.
This both leads to significant performance improvements, and makes
future just-in-time compilation of expressions easier.
The speed gains primarily come from:
- non-recursive implementation reduces stack usage / overhead
- simple sub-expressions are implemented with a single jump, without
function calls
- sharing some state between different sub-expressions
- reduced amount of indirect/hard to predict memory accesses by laying
out operation metadata sequentially; including the avoidance of
nearly all of the previously used linked lists
- more code has been moved to expression initialization, avoiding
constant re-checks at evaluation time
Future just-in-time compilation (JIT) has become easier, as
demonstrated by released patches intended to be merged in a later
release, for primarily two reasons: Firstly, due to a stricter split
between expression initialization and evaluation, less code has to be
handled by the JIT. Secondly, due to the non-recursive nature of the
generated "instructions", less performance-critical code-paths can
easily be shared between interpreted and compiled evaluation.
The new framework allows for significant future optimizations. E.g.:
- basic infrastructure for to later reduce the per executor-startup
overhead of expression evaluation, by caching state in prepared
statements. That'd be helpful in OLTPish scenarios where
initialization overhead is measurable.
- optimizing the generated "code". A number of proposals for potential
work has already been made.
- optimizing the interpreter. Similarly a number of proposals have
been made here too.
The move of logic into the expression initialization step leads to some
backward-incompatible changes:
- Function permission checks are now done during expression
initialization, whereas previously they were done during
execution. In edge cases this can lead to errors being raised that
previously wouldn't have been, e.g. a NULL array being coerced to a
different array type previously didn't perform checks.
- The set of domain constraints to be checked, is now evaluated once
during expression initialization, previously it was re-built
every time a domain check was evaluated. For normal queries this
doesn't change much, but e.g. for plpgsql functions, which caches
ExprStates, the old set could stick around longer. The behavior
around might still change.
Author: Andres Freund, with significant changes by Tom Lane,
changes by Heikki Linnakangas
Reviewed-By: Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de
2017-03-14 23:45:36 +01:00
|
|
|
indexInfo->ii_PredicateState = NULL;
|
2006-08-25 06:06:58 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
/*
|
|
|
|
* index_set_state_flags - adjust pg_index state flags
|
|
|
|
*
|
|
|
|
* This is used during CREATE/DROP INDEX CONCURRENTLY to adjust the pg_index
|
2013-08-01 16:46:19 +02:00
|
|
|
* flags that denote the index's state. Because the update is not
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* transactional and will not roll back on error, this must only be used as
|
|
|
|
* the last step in a transaction that has not made any transactional catalog
|
|
|
|
* updates!
|
|
|
|
*
|
|
|
|
* Note that heap_inplace_update does send a cache inval message for the
|
|
|
|
* tuple, so other sessions will hear about the update as soon as we commit.
|
2013-08-01 16:46:19 +02:00
|
|
|
*
|
|
|
|
* NB: In releases prior to PostgreSQL 9.4, the use of a non-transactional
|
|
|
|
* update here would have been unsafe; now that MVCC rules apply even for
|
|
|
|
* system catalog scans, we could potentially use a transactional update here
|
|
|
|
* instead.
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
index_set_state_flags(Oid indexId, IndexStateFlagsAction action)
|
|
|
|
{
|
|
|
|
Relation pg_index;
|
|
|
|
HeapTuple indexTuple;
|
|
|
|
Form_pg_index indexForm;
|
|
|
|
|
|
|
|
/* Assert that current xact hasn't done any transactional updates */
|
|
|
|
Assert(GetTopTransactionIdIfAny() == InvalidTransactionId);
|
|
|
|
|
|
|
|
/* Open pg_index and fetch a writable copy of the index's tuple */
|
|
|
|
pg_index = heap_open(IndexRelationId, RowExclusiveLock);
|
|
|
|
|
|
|
|
indexTuple = SearchSysCacheCopy1(INDEXRELID,
|
|
|
|
ObjectIdGetDatum(indexId));
|
|
|
|
if (!HeapTupleIsValid(indexTuple))
|
|
|
|
elog(ERROR, "cache lookup failed for index %u", indexId);
|
|
|
|
indexForm = (Form_pg_index) GETSTRUCT(indexTuple);
|
|
|
|
|
|
|
|
/* Perform the requested state change on the copy */
|
|
|
|
switch (action)
|
|
|
|
{
|
|
|
|
case INDEX_CREATE_SET_READY:
|
|
|
|
/* Set indisready during a CREATE INDEX CONCURRENTLY sequence */
|
|
|
|
Assert(indexForm->indislive);
|
|
|
|
Assert(!indexForm->indisready);
|
|
|
|
Assert(!indexForm->indisvalid);
|
|
|
|
indexForm->indisready = true;
|
|
|
|
break;
|
|
|
|
case INDEX_CREATE_SET_VALID:
|
|
|
|
/* Set indisvalid during a CREATE INDEX CONCURRENTLY sequence */
|
|
|
|
Assert(indexForm->indislive);
|
|
|
|
Assert(indexForm->indisready);
|
|
|
|
Assert(!indexForm->indisvalid);
|
|
|
|
indexForm->indisvalid = true;
|
|
|
|
break;
|
|
|
|
case INDEX_DROP_CLEAR_VALID:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear indisvalid during a DROP INDEX CONCURRENTLY sequence
|
|
|
|
*
|
|
|
|
* If indisready == true we leave it set so the index still gets
|
|
|
|
* maintained by active transactions. We only need to ensure that
|
|
|
|
* indisvalid is false. (We don't assert that either is initially
|
|
|
|
* true, though, since we want to be able to retry a DROP INDEX
|
|
|
|
* CONCURRENTLY that failed partway through.)
|
|
|
|
*
|
|
|
|
* Note: the CLUSTER logic assumes that indisclustered cannot be
|
|
|
|
* set on any invalid index, so clear that flag too.
|
|
|
|
*/
|
|
|
|
indexForm->indisvalid = false;
|
|
|
|
indexForm->indisclustered = false;
|
|
|
|
break;
|
|
|
|
case INDEX_DROP_SET_DEAD:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear indisready/indislive during DROP INDEX CONCURRENTLY
|
|
|
|
*
|
|
|
|
* We clear both indisready and indislive, because we not only
|
|
|
|
* want to stop updates, we want to prevent sessions from touching
|
|
|
|
* the index at all.
|
|
|
|
*/
|
|
|
|
Assert(!indexForm->indisvalid);
|
|
|
|
indexForm->indisready = false;
|
|
|
|
indexForm->indislive = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ... and write it back in-place */
|
|
|
|
heap_inplace_update(pg_index, indexTuple);
|
|
|
|
|
|
|
|
heap_close(pg_index, RowExclusiveLock);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1999-11-21 21:01:10 +01:00
|
|
|
/*
|
|
|
|
* IndexGetRelation: given an index's relation OID, get the OID of the
|
2014-05-06 18:12:18 +02:00
|
|
|
* relation it is an index on. Uses the system cache.
|
1999-11-21 21:01:10 +01:00
|
|
|
*/
|
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice:
look up the name, do permissions checks, and then lock the table; or
look up the name, lock the table, and then do permissions checks.
The first choice was wrong because the results of the name lookup
and permissions checks might be out-of-date by the time the table
lock was acquired, while the second allowed a user with no privileges
to interfere with access to a table by users who do have privileges
(e.g. if a malicious backend queues up for an AccessExclusiveLock on
a table on which AccessShareLock is already held, further attempts
to access the table will be blocked until the AccessExclusiveLock
is obtained and the malicious backend's transaction rolls back).
To fix, allow callers of RangeVarGetRelid() to pass a callback which
gets executed after performing the name lookup but before acquiring
the relation lock. If the name lookup is retried (because
invalidation messages are received), the callback will be re-executed
as well, so we get the best of both worlds. RangeVarGetRelid() is
renamed to RangeVarGetRelidExtended(); callers not wishing to supply
a callback can continue to invoke it as RangeVarGetRelid(), which is
now a macro. Since the only one caller that uses nowait = true now
passes a callback anyway, the RangeVarGetRelid() macro defaults nowait
as well. The callback can also be used for supplemental locking - for
example, REINDEX INDEX needs to acquire the table lock before the index
lock to reduce deadlock possibilities.
There's a lot more work to be done here to fix all the cases where this
can be a problem, but this commit provides the general infrastructure
and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE,
LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE.
Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
|
|
|
Oid
|
|
|
|
IndexGetRelation(Oid indexId, bool missing_ok)
|
1999-11-21 21:01:10 +01:00
|
|
|
{
|
|
|
|
HeapTuple tuple;
|
|
|
|
Form_pg_index index;
|
2000-11-16 23:30:52 +01:00
|
|
|
Oid result;
|
1999-11-21 21:01:10 +01:00
|
|
|
|
2010-02-14 19:42:19 +01:00
|
|
|
tuple = SearchSysCache1(INDEXRELID, ObjectIdGetDatum(indexId));
|
1999-11-21 21:01:10 +01:00
|
|
|
if (!HeapTupleIsValid(tuple))
|
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice:
look up the name, do permissions checks, and then lock the table; or
look up the name, lock the table, and then do permissions checks.
The first choice was wrong because the results of the name lookup
and permissions checks might be out-of-date by the time the table
lock was acquired, while the second allowed a user with no privileges
to interfere with access to a table by users who do have privileges
(e.g. if a malicious backend queues up for an AccessExclusiveLock on
a table on which AccessShareLock is already held, further attempts
to access the table will be blocked until the AccessExclusiveLock
is obtained and the malicious backend's transaction rolls back).
To fix, allow callers of RangeVarGetRelid() to pass a callback which
gets executed after performing the name lookup but before acquiring
the relation lock. If the name lookup is retried (because
invalidation messages are received), the callback will be re-executed
as well, so we get the best of both worlds. RangeVarGetRelid() is
renamed to RangeVarGetRelidExtended(); callers not wishing to supply
a callback can continue to invoke it as RangeVarGetRelid(), which is
now a macro. Since the only one caller that uses nowait = true now
passes a callback anyway, the RangeVarGetRelid() macro defaults nowait
as well. The callback can also be used for supplemental locking - for
example, REINDEX INDEX needs to acquire the table lock before the index
lock to reduce deadlock possibilities.
There's a lot more work to be done here to fix all the cases where this
can be a problem, but this commit provides the general infrastructure
and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE,
LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE.
Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
|
|
|
{
|
|
|
|
if (missing_ok)
|
|
|
|
return InvalidOid;
|
2003-07-21 03:59:11 +02:00
|
|
|
elog(ERROR, "cache lookup failed for index %u", indexId);
|
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice:
look up the name, do permissions checks, and then lock the table; or
look up the name, lock the table, and then do permissions checks.
The first choice was wrong because the results of the name lookup
and permissions checks might be out-of-date by the time the table
lock was acquired, while the second allowed a user with no privileges
to interfere with access to a table by users who do have privileges
(e.g. if a malicious backend queues up for an AccessExclusiveLock on
a table on which AccessShareLock is already held, further attempts
to access the table will be blocked until the AccessExclusiveLock
is obtained and the malicious backend's transaction rolls back).
To fix, allow callers of RangeVarGetRelid() to pass a callback which
gets executed after performing the name lookup but before acquiring
the relation lock. If the name lookup is retried (because
invalidation messages are received), the callback will be re-executed
as well, so we get the best of both worlds. RangeVarGetRelid() is
renamed to RangeVarGetRelidExtended(); callers not wishing to supply
a callback can continue to invoke it as RangeVarGetRelid(), which is
now a macro. Since the only one caller that uses nowait = true now
passes a callback anyway, the RangeVarGetRelid() macro defaults nowait
as well. The callback can also be used for supplemental locking - for
example, REINDEX INDEX needs to acquire the table lock before the index
lock to reduce deadlock possibilities.
There's a lot more work to be done here to fix all the cases where this
can be a problem, but this commit provides the general infrastructure
and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE,
LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE.
Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
|
|
|
}
|
1999-11-21 21:01:10 +01:00
|
|
|
index = (Form_pg_index) GETSTRUCT(tuple);
|
|
|
|
Assert(index->indexrelid == indexId);
|
|
|
|
|
2000-11-16 23:30:52 +01:00
|
|
|
result = index->indrelid;
|
|
|
|
ReleaseSysCache(tuple);
|
|
|
|
return result;
|
1999-11-21 21:01:10 +01:00
|
|
|
}
|
|
|
|
|
2003-09-24 20:54:02 +02:00
|
|
|
/*
|
|
|
|
* reindex_index - This routine is used to recreate a single index
|
2000-02-18 10:30:20 +01:00
|
|
|
*/
|
2003-09-24 20:54:02 +02:00
|
|
|
void
|
2015-05-15 13:09:57 +02:00
|
|
|
reindex_index(Oid indexId, bool skip_constraint_checks, char persistence,
|
2015-05-24 03:35:49 +02:00
|
|
|
int options)
|
2000-02-18 10:30:20 +01:00
|
|
|
{
|
2000-04-12 19:17:23 +02:00
|
|
|
Relation iRel,
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
heapRelation;
|
2001-10-07 01:21:45 +02:00
|
|
|
Oid heapId;
|
2009-03-27 16:57:11 +01:00
|
|
|
IndexInfo *indexInfo;
|
2010-02-07 23:40:33 +01:00
|
|
|
volatile bool skipped_constraint = false;
|
2015-05-15 13:09:57 +02:00
|
|
|
PGRUsage ru0;
|
|
|
|
|
|
|
|
pg_rusage_init(&ru0);
|
2000-02-18 10:30:20 +01:00
|
|
|
|
2001-11-20 03:46:13 +01:00
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Open and lock the parent heap relation. ShareLock is sufficient since
|
2005-10-15 04:49:52 +02:00
|
|
|
* we only need to be sure no schema or data changes are going on.
|
2004-10-01 19:11:50 +02:00
|
|
|
*/
|
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice:
look up the name, do permissions checks, and then lock the table; or
look up the name, lock the table, and then do permissions checks.
The first choice was wrong because the results of the name lookup
and permissions checks might be out-of-date by the time the table
lock was acquired, while the second allowed a user with no privileges
to interfere with access to a table by users who do have privileges
(e.g. if a malicious backend queues up for an AccessExclusiveLock on
a table on which AccessShareLock is already held, further attempts
to access the table will be blocked until the AccessExclusiveLock
is obtained and the malicious backend's transaction rolls back).
To fix, allow callers of RangeVarGetRelid() to pass a callback which
gets executed after performing the name lookup but before acquiring
the relation lock. If the name lookup is retried (because
invalidation messages are received), the callback will be re-executed
as well, so we get the best of both worlds. RangeVarGetRelid() is
renamed to RangeVarGetRelidExtended(); callers not wishing to supply
a callback can continue to invoke it as RangeVarGetRelid(), which is
now a macro. Since the only one caller that uses nowait = true now
passes a callback anyway, the RangeVarGetRelid() macro defaults nowait
as well. The callback can also be used for supplemental locking - for
example, REINDEX INDEX needs to acquire the table lock before the index
lock to reduce deadlock possibilities.
There's a lot more work to be done here to fix all the cases where this
can be a problem, but this commit provides the general infrastructure
and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE,
LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE.
Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
|
|
|
heapId = IndexGetRelation(indexId, false);
|
2004-10-01 19:11:50 +02:00
|
|
|
heapRelation = heap_open(heapId, ShareLock);
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Open the target index relation and get an exclusive lock on it, to
|
|
|
|
* ensure that no one else is touching this particular index.
|
2001-11-20 03:46:13 +01:00
|
|
|
*/
|
2006-07-31 22:09:10 +02:00
|
|
|
iRel = index_open(indexId, AccessExclusiveLock);
|
2001-11-20 03:46:13 +01:00
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
/*
|
|
|
|
* The case of reindexing partitioned tables and indexes is handled
|
|
|
|
* differently by upper layers, so this case shouldn't arise.
|
|
|
|
*/
|
|
|
|
if (iRel->rd_rel->relkind == RELKIND_PARTITIONED_INDEX)
|
|
|
|
elog(ERROR, "unsupported relation kind for index \"%s\"",
|
|
|
|
RelationGetRelationName(iRel));
|
|
|
|
|
2008-01-30 20:46:48 +01:00
|
|
|
/*
|
|
|
|
* Don't allow reindex on temp tables of other backends ... their local
|
|
|
|
* buffer manager is not going to cope.
|
|
|
|
*/
|
2009-04-01 00:12:48 +02:00
|
|
|
if (RELATION_IS_OTHER_TEMP(iRel))
|
2008-01-30 20:46:48 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
errmsg("cannot reindex temporary tables of other sessions")));
|
2008-01-30 20:46:48 +01:00
|
|
|
|
|
|
|
/*
|
2009-06-11 16:49:15 +02:00
|
|
|
* Also check for active uses of the index in the current transaction; we
|
|
|
|
* don't want to reindex underneath an open indexscan.
|
2008-01-30 20:46:48 +01:00
|
|
|
*/
|
|
|
|
CheckTableNotInUse(iRel, "REINDEX INDEX");
|
|
|
|
|
2011-06-08 12:47:21 +02:00
|
|
|
/*
|
|
|
|
* All predicate locks on the index are about to be made invalid. Promote
|
|
|
|
* them to relation locks on the heap.
|
|
|
|
*/
|
|
|
|
TransferPredicateLocksToHeapRelation(iRel);
|
|
|
|
|
2004-08-01 19:32:22 +02:00
|
|
|
PG_TRY();
|
2000-12-08 07:17:58 +01:00
|
|
|
{
|
2004-08-01 19:32:22 +02:00
|
|
|
/* Suppress use of the target index while rebuilding it */
|
|
|
|
SetReindexProcessing(heapId, indexId);
|
|
|
|
|
|
|
|
/* Fetch info needed for index_build */
|
|
|
|
indexInfo = BuildIndexInfo(iRel);
|
|
|
|
|
2010-02-07 23:40:33 +01:00
|
|
|
/* If requested, skip checking uniqueness/exclusion constraints */
|
|
|
|
if (skip_constraint_checks)
|
|
|
|
{
|
|
|
|
if (indexInfo->ii_Unique || indexInfo->ii_ExclusionOps != NULL)
|
|
|
|
skipped_constraint = true;
|
|
|
|
indexInfo->ii_Unique = false;
|
|
|
|
indexInfo->ii_ExclusionOps = NULL;
|
|
|
|
indexInfo->ii_ExclusionProcs = NULL;
|
|
|
|
indexInfo->ii_ExclusionStrats = NULL;
|
|
|
|
}
|
|
|
|
|
2010-02-07 21:48:13 +01:00
|
|
|
/* We'll build a new physical relation for the index */
|
2014-11-17 15:23:35 +01:00
|
|
|
RelationSetNewRelfilenode(iRel, persistence, InvalidTransactionId,
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
InvalidMultiXactId);
|
2004-08-01 19:32:22 +02:00
|
|
|
|
|
|
|
/* Initialize the index and rebuild */
|
2006-07-31 03:16:38 +02:00
|
|
|
/* Note: we do not need to re-establish pkey setting */
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
index_build(heapRelation, iRel, indexInfo, false, true, true);
|
2000-12-08 07:17:58 +01:00
|
|
|
}
|
2004-08-01 19:32:22 +02:00
|
|
|
PG_CATCH();
|
2001-11-20 03:46:13 +01:00
|
|
|
{
|
2004-08-01 19:32:22 +02:00
|
|
|
/* Make sure flag gets cleared on error exit */
|
|
|
|
ResetReindexProcessing();
|
|
|
|
PG_RE_THROW();
|
2001-11-20 03:46:13 +01:00
|
|
|
}
|
2004-08-01 19:32:22 +02:00
|
|
|
PG_END_TRY();
|
|
|
|
ResetReindexProcessing();
|
2006-05-11 01:18:39 +02:00
|
|
|
|
2006-08-25 06:06:58 +02:00
|
|
|
/*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* If the index is marked invalid/not-ready/dead (ie, it's from a failed
|
|
|
|
* CREATE INDEX CONCURRENTLY, or a DROP INDEX CONCURRENTLY failed midway),
|
|
|
|
* and we didn't skip a uniqueness check, we can now mark it valid. This
|
|
|
|
* allows REINDEX to be used to clean up in such cases.
|
2009-03-27 16:57:11 +01:00
|
|
|
*
|
|
|
|
* We can also reset indcheckxmin, because we have now done a
|
|
|
|
* non-concurrent index build, *except* in the case where index_build
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* found some still-broken HOT chains. If it did, and we don't have to
|
|
|
|
* change any of the other flags, we just leave indcheckxmin alone (note
|
|
|
|
* that index_build won't have changed it, because this is a reindex).
|
|
|
|
* This is okay and desirable because not updating the tuple leaves the
|
|
|
|
* index's usability horizon (recorded as the tuple's xmin value) the same
|
|
|
|
* as it was.
|
2011-04-20 00:50:56 +02:00
|
|
|
*
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* But, if the index was invalid/not-ready/dead and there were broken HOT
|
|
|
|
* chains, we had better force indcheckxmin true, because the normal
|
|
|
|
* argument that the HOT chains couldn't conflict with the index is
|
|
|
|
* suspect for an invalid index. (A conflict is definitely possible if
|
2014-05-06 18:12:18 +02:00
|
|
|
* the index was dead. It probably shouldn't happen otherwise, but let's
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
* be conservative.) In this case advancing the usability horizon is
|
|
|
|
* appropriate.
|
|
|
|
*
|
|
|
|
* Another reason for avoiding unnecessary updates here is that while
|
|
|
|
* reindexing pg_index itself, we must not try to update tuples in it.
|
|
|
|
* pg_index's indexes should always have these flags in their clean state,
|
|
|
|
* so that won't happen.
|
2016-06-10 16:25:31 +02:00
|
|
|
*
|
|
|
|
* If early pruning/vacuuming is enabled for the heap relation, the
|
|
|
|
* usability horizon must be advanced to the current transaction on every
|
|
|
|
* build or rebuild. pg_index is OK in this regard because catalog tables
|
|
|
|
* are not subject to early cleanup.
|
2006-08-25 06:06:58 +02:00
|
|
|
*/
|
2011-04-19 22:55:34 +02:00
|
|
|
if (!skipped_constraint)
|
2010-02-07 23:40:33 +01:00
|
|
|
{
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
Relation pg_index;
|
|
|
|
HeapTuple indexTuple;
|
|
|
|
Form_pg_index indexForm;
|
|
|
|
bool index_bad;
|
2016-06-10 18:24:01 +02:00
|
|
|
bool early_pruning_enabled = EarlyPruningEnabled(heapRelation);
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
|
2010-02-07 23:40:33 +01:00
|
|
|
pg_index = heap_open(IndexRelationId, RowExclusiveLock);
|
2006-08-25 06:06:58 +02:00
|
|
|
|
2010-02-14 19:42:19 +01:00
|
|
|
indexTuple = SearchSysCacheCopy1(INDEXRELID,
|
|
|
|
ObjectIdGetDatum(indexId));
|
2010-02-07 23:40:33 +01:00
|
|
|
if (!HeapTupleIsValid(indexTuple))
|
|
|
|
elog(ERROR, "cache lookup failed for index %u", indexId);
|
|
|
|
indexForm = (Form_pg_index) GETSTRUCT(indexTuple);
|
2006-08-25 06:06:58 +02:00
|
|
|
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
index_bad = (!indexForm->indisvalid ||
|
|
|
|
!indexForm->indisready ||
|
|
|
|
!indexForm->indislive);
|
|
|
|
if (index_bad ||
|
2016-06-10 16:25:31 +02:00
|
|
|
(indexForm->indcheckxmin && !indexInfo->ii_BrokenHotChain) ||
|
2016-06-10 18:24:01 +02:00
|
|
|
early_pruning_enabled)
|
2010-02-07 23:40:33 +01:00
|
|
|
{
|
2016-06-10 18:24:01 +02:00
|
|
|
if (!indexInfo->ii_BrokenHotChain && !early_pruning_enabled)
|
2010-02-07 23:40:33 +01:00
|
|
|
indexForm->indcheckxmin = false;
|
2016-06-10 18:24:01 +02:00
|
|
|
else if (index_bad || early_pruning_enabled)
|
2011-04-21 01:01:20 +02:00
|
|
|
indexForm->indcheckxmin = true;
|
|
|
|
indexForm->indisvalid = true;
|
|
|
|
indexForm->indisready = true;
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
indexForm->indislive = true;
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(pg_index, &indexTuple->t_self, indexTuple);
|
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Invalidate the relcache for the table, so that after we commit
|
|
|
|
* all sessions will refresh the table's index list. This ensures
|
|
|
|
* that if anyone misses seeing the pg_index row during this
|
|
|
|
* update, they'll refresh their list before attempting any update
|
|
|
|
* on the table.
|
|
|
|
*/
|
|
|
|
CacheInvalidateRelcache(heapRelation);
|
2010-02-07 23:40:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
heap_close(pg_index, RowExclusiveLock);
|
2006-08-25 06:06:58 +02:00
|
|
|
}
|
|
|
|
|
2015-05-15 13:09:57 +02:00
|
|
|
/* Log what we did */
|
|
|
|
if (options & REINDEXOPT_VERBOSE)
|
|
|
|
ereport(INFO,
|
|
|
|
(errmsg("index \"%s\" was reindexed",
|
|
|
|
get_rel_name(indexId)),
|
2017-06-04 17:41:16 +02:00
|
|
|
errdetail_internal("%s",
|
2017-06-13 19:05:59 +02:00
|
|
|
pg_rusage_show(&ru0))));
|
2015-05-15 13:09:57 +02:00
|
|
|
|
2006-05-11 01:18:39 +02:00
|
|
|
/* Close rels, but keep locks */
|
2006-07-31 22:09:10 +02:00
|
|
|
index_close(iRel, NoLock);
|
2006-05-11 01:18:39 +02:00
|
|
|
heap_close(heapRelation, NoLock);
|
2000-02-18 10:30:20 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2003-09-24 20:54:02 +02:00
|
|
|
* reindex_relation - This routine is used to recreate all indexes
|
2004-05-08 02:34:49 +02:00
|
|
|
* of a relation (and optionally its toast relation too, if any).
|
2002-09-23 02:42:48 +02:00
|
|
|
*
|
2011-04-16 23:26:41 +02:00
|
|
|
* "flags" is a bitmask that can include any combination of these bits:
|
2010-02-07 21:48:13 +01:00
|
|
|
*
|
2011-04-16 23:26:41 +02:00
|
|
|
* REINDEX_REL_PROCESS_TOAST: if true, process the toast table too (if any).
|
|
|
|
*
|
|
|
|
* REINDEX_REL_SUPPRESS_INDEX_USE: if true, the relation was just completely
|
2011-01-21 04:44:10 +01:00
|
|
|
* rebuilt by an operation such as VACUUM FULL or CLUSTER, and therefore its
|
|
|
|
* indexes are inconsistent with it. This makes things tricky if the relation
|
|
|
|
* is a system catalog that we might consult during the reindexing. To deal
|
|
|
|
* with that case, we mark all of the indexes as pending rebuild so that they
|
|
|
|
* won't be trusted until rebuilt. The caller is required to call us *without*
|
2011-04-16 23:26:41 +02:00
|
|
|
* having made the rebuilt table visible by doing CommandCounterIncrement;
|
2011-01-21 04:44:10 +01:00
|
|
|
* we'll do CCI after having collected the index list. (This way we can still
|
|
|
|
* use catalog indexes while collecting the list.)
|
|
|
|
*
|
2011-04-16 23:26:41 +02:00
|
|
|
* REINDEX_REL_CHECK_CONSTRAINTS: if true, recheck unique and exclusion
|
|
|
|
* constraint conditions, else don't. To avoid deadlocks, VACUUM FULL or
|
|
|
|
* CLUSTER on a system catalog must omit this flag. REINDEX should be used to
|
|
|
|
* rebuild an index if constraint inconsistency is suspected. For optimal
|
|
|
|
* performance, other callers should include the flag only after transforming
|
|
|
|
* the data in a manner that risks a change in constraint validity.
|
2010-02-07 23:40:33 +01:00
|
|
|
*
|
2014-11-15 05:19:49 +01:00
|
|
|
* REINDEX_REL_FORCE_INDEXES_UNLOGGED: if true, set the persistence of the
|
|
|
|
* rebuilt indexes to unlogged.
|
|
|
|
*
|
2015-04-08 13:55:43 +02:00
|
|
|
* REINDEX_REL_FORCE_INDEXES_PERMANENT: if true, set the persistence of the
|
2014-11-15 05:19:49 +01:00
|
|
|
* rebuilt indexes to permanent.
|
|
|
|
*
|
2011-04-16 23:26:41 +02:00
|
|
|
* Returns true if any indexes were rebuilt (including toast table's index
|
2014-05-06 18:12:18 +02:00
|
|
|
* when relevant). Note that a CommandCounterIncrement will occur after each
|
2011-04-16 23:26:41 +02:00
|
|
|
* index rebuild.
|
2000-02-18 10:30:20 +01:00
|
|
|
*/
|
|
|
|
bool
|
2015-05-15 13:09:57 +02:00
|
|
|
reindex_relation(Oid relid, int flags, int options)
|
2000-02-18 10:30:20 +01:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
Relation rel;
|
2003-09-24 20:54:02 +02:00
|
|
|
Oid toast_relid;
|
2010-02-07 21:48:13 +01:00
|
|
|
List *indexIds;
|
2003-09-24 20:54:02 +02:00
|
|
|
bool is_pg_class;
|
|
|
|
bool result;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2001-08-18 01:50:00 +02:00
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Open and lock the relation. ShareLock is sufficient since we only need
|
2011-07-09 04:19:30 +02:00
|
|
|
* to prevent schema and data changes in it. The lock level used here
|
|
|
|
* should match ReindexTable().
|
2001-08-18 01:50:00 +02:00
|
|
|
*/
|
2004-10-01 19:11:50 +02:00
|
|
|
rel = heap_open(relid, ShareLock);
|
2001-10-25 07:50:21 +02:00
|
|
|
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
/*
|
|
|
|
* This may be useful when implemented someday; but that day is not today.
|
|
|
|
* For now, avoid erroring out when called in a multi-table context
|
|
|
|
* (REINDEX SCHEMA) and happen to come across a partitioned table. The
|
|
|
|
* partitions may be reindexed on their own anyway.
|
|
|
|
*/
|
|
|
|
if (rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
|
|
|
|
{
|
|
|
|
ereport(WARNING,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("REINDEX of partitioned tables is not yet implemented, skipping \"%s\"",
|
|
|
|
RelationGetRelationName(rel))));
|
|
|
|
heap_close(rel, ShareLock);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2003-09-24 20:54:02 +02:00
|
|
|
toast_relid = rel->rd_rel->reltoastrelid;
|
|
|
|
|
2000-12-08 07:17:58 +01:00
|
|
|
/*
|
2003-09-24 20:54:02 +02:00
|
|
|
* Get the list of index OIDs for this relation. (We trust to the
|
|
|
|
* relcache to get this with a sequential scan if ignoring system
|
|
|
|
* indexes.)
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
2003-09-24 20:54:02 +02:00
|
|
|
indexIds = RelationGetIndexList(rel);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2001-02-23 10:26:14 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* reindex_index will attempt to update the pg_class rows for the relation
|
|
|
|
* and index. If we are processing pg_class itself, we want to make sure
|
|
|
|
* that the updates do not try to insert index entries into indexes we
|
2014-05-06 18:12:18 +02:00
|
|
|
* have not processed yet. (When we are trying to recover from corrupted
|
2005-10-15 04:49:52 +02:00
|
|
|
* indexes, that could easily cause a crash.) We can accomplish this
|
2017-03-02 12:33:50 +01:00
|
|
|
* because CatalogTupleInsert/CatalogTupleUpdate will use the relcache's
|
|
|
|
* index list to know which indexes to update. We just force the index
|
|
|
|
* list to be only the stuff we've processed.
|
2003-09-24 20:54:02 +02:00
|
|
|
*
|
2005-10-15 04:49:52 +02:00
|
|
|
* It is okay to not insert entries into the indexes we have not processed
|
|
|
|
* yet because all of this is transaction-safe. If we fail partway
|
|
|
|
* through, the updated rows are dead and it doesn't matter whether they
|
2014-05-06 18:12:18 +02:00
|
|
|
* have index entries. Also, a new pg_class index will be created with a
|
2010-02-07 21:48:13 +01:00
|
|
|
* correct entry for its own pg_class row because we do
|
|
|
|
* RelationSetNewRelfilenode() before we do index_build().
|
2005-08-12 03:36:05 +02:00
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* Note that we also clear pg_class's rd_oidindex until the loop is done,
|
|
|
|
* so that that index can't be accessed either. This means we cannot
|
|
|
|
* safely generate new relation OIDs while in the loop; shouldn't be a
|
|
|
|
* problem.
|
2001-02-23 10:26:14 +01:00
|
|
|
*/
|
2005-04-14 03:38:22 +02:00
|
|
|
is_pg_class = (RelationGetRelid(rel) == RelationRelationId);
|
2008-08-10 21:02:33 +02:00
|
|
|
|
|
|
|
/* Ensure rd_indexattr is valid; see comments for RelationSetIndexList */
|
|
|
|
if (is_pg_class)
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
2013-12-11 00:33:45 +01:00
|
|
|
(void) RelationGetIndexAttrBitmap(rel, INDEX_ATTR_BITMAP_ALL);
|
2003-09-24 20:54:02 +02:00
|
|
|
|
2010-02-07 21:48:13 +01:00
|
|
|
PG_TRY();
|
2001-02-23 10:26:14 +01:00
|
|
|
{
|
2010-02-07 21:48:13 +01:00
|
|
|
List *doneIndexes;
|
|
|
|
ListCell *indexId;
|
2014-11-15 05:19:49 +01:00
|
|
|
char persistence;
|
2001-10-25 07:50:21 +02:00
|
|
|
|
2011-04-16 23:26:41 +02:00
|
|
|
if (flags & REINDEX_REL_SUPPRESS_INDEX_USE)
|
2010-02-07 21:48:13 +01:00
|
|
|
{
|
|
|
|
/* Suppress use of all the indexes until they are rebuilt */
|
|
|
|
SetReindexPending(indexIds);
|
2002-09-23 02:42:48 +02:00
|
|
|
|
2010-02-07 21:48:13 +01:00
|
|
|
/*
|
|
|
|
* Make the new heap contents visible --- now things might be
|
|
|
|
* inconsistent!
|
|
|
|
*/
|
|
|
|
CommandCounterIncrement();
|
|
|
|
}
|
2003-09-24 20:54:02 +02:00
|
|
|
|
2014-11-15 05:19:49 +01:00
|
|
|
/*
|
|
|
|
* Compute persistence of indexes: same as that of owning rel, unless
|
|
|
|
* caller specified otherwise.
|
|
|
|
*/
|
|
|
|
if (flags & REINDEX_REL_FORCE_INDEXES_UNLOGGED)
|
|
|
|
persistence = RELPERSISTENCE_UNLOGGED;
|
|
|
|
else if (flags & REINDEX_REL_FORCE_INDEXES_PERMANENT)
|
|
|
|
persistence = RELPERSISTENCE_PERMANENT;
|
|
|
|
else
|
|
|
|
persistence = rel->rd_rel->relpersistence;
|
|
|
|
|
2010-02-07 21:48:13 +01:00
|
|
|
/* Reindex all the indexes. */
|
|
|
|
doneIndexes = NIL;
|
|
|
|
foreach(indexId, indexIds)
|
|
|
|
{
|
|
|
|
Oid indexOid = lfirst_oid(indexId);
|
|
|
|
|
|
|
|
if (is_pg_class)
|
|
|
|
RelationSetIndexList(rel, doneIndexes, InvalidOid);
|
2003-09-24 20:54:02 +02:00
|
|
|
|
2014-11-15 05:19:49 +01:00
|
|
|
reindex_index(indexOid, !(flags & REINDEX_REL_CHECK_CONSTRAINTS),
|
2015-05-15 13:09:57 +02:00
|
|
|
persistence, options);
|
2010-02-07 21:48:13 +01:00
|
|
|
|
|
|
|
CommandCounterIncrement();
|
|
|
|
|
2011-06-06 04:30:04 +02:00
|
|
|
/* Index should no longer be in the pending list */
|
|
|
|
Assert(!ReindexIsProcessingIndex(indexOid));
|
2010-02-07 21:48:13 +01:00
|
|
|
|
|
|
|
if (is_pg_class)
|
|
|
|
doneIndexes = lappend_oid(doneIndexes, indexOid);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
PG_CATCH();
|
|
|
|
{
|
|
|
|
/* Make sure list gets cleared on error exit */
|
|
|
|
ResetReindexPending();
|
|
|
|
PG_RE_THROW();
|
2003-09-23 03:51:09 +02:00
|
|
|
}
|
2010-02-07 21:48:13 +01:00
|
|
|
PG_END_TRY();
|
|
|
|
ResetReindexPending();
|
2003-09-23 03:51:09 +02:00
|
|
|
|
2003-09-24 20:54:02 +02:00
|
|
|
if (is_pg_class)
|
2005-08-12 03:36:05 +02:00
|
|
|
RelationSetIndexList(rel, indexIds, ClassOidIndexId);
|
2003-09-24 20:54:02 +02:00
|
|
|
|
2002-09-23 02:42:48 +02:00
|
|
|
/*
|
2003-09-24 20:54:02 +02:00
|
|
|
* Close rel, but continue to hold the lock.
|
2002-09-23 02:42:48 +02:00
|
|
|
*/
|
|
|
|
heap_close(rel, NoLock);
|
|
|
|
|
2003-09-24 20:54:02 +02:00
|
|
|
result = (indexIds != NIL);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2003-09-24 20:54:02 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* If the relation has a secondary toast rel, reindex that too while we
|
2011-04-16 23:26:41 +02:00
|
|
|
* still hold the lock on the master table.
|
2003-09-24 20:54:02 +02:00
|
|
|
*/
|
2011-04-16 23:26:41 +02:00
|
|
|
if ((flags & REINDEX_REL_PROCESS_TOAST) && OidIsValid(toast_relid))
|
2015-05-15 13:09:57 +02:00
|
|
|
result |= reindex_relation(toast_relid, flags, options);
|
2000-12-08 07:17:58 +01:00
|
|
|
|
2003-09-24 20:54:02 +02:00
|
|
|
return result;
|
2000-02-18 10:30:20 +01:00
|
|
|
}
|
2010-02-07 21:48:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* System index reindexing support
|
|
|
|
*
|
|
|
|
* When we are busy reindexing a system index, this code provides support
|
2011-06-06 04:30:04 +02:00
|
|
|
* for preventing catalog lookups from using that index. We also make use
|
|
|
|
* of this to catch attempted uses of user indexes during reindexing of
|
2018-01-19 13:48:44 +01:00
|
|
|
* those indexes. This information is propagated to parallel workers;
|
|
|
|
* attempting to change it during a parallel operation is not permitted.
|
2010-02-07 21:48:13 +01:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
static Oid currentlyReindexedHeap = InvalidOid;
|
|
|
|
static Oid currentlyReindexedIndex = InvalidOid;
|
|
|
|
static List *pendingReindexedIndexes = NIL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ReindexIsProcessingHeap
|
|
|
|
* True if heap specified by OID is currently being reindexed.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
ReindexIsProcessingHeap(Oid heapOid)
|
|
|
|
{
|
|
|
|
return heapOid == currentlyReindexedHeap;
|
|
|
|
}
|
|
|
|
|
2011-06-06 04:30:04 +02:00
|
|
|
/*
|
|
|
|
* ReindexIsCurrentlyProcessingIndex
|
|
|
|
* True if index specified by OID is currently being reindexed.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
ReindexIsCurrentlyProcessingIndex(Oid indexOid)
|
|
|
|
{
|
|
|
|
return indexOid == currentlyReindexedIndex;
|
|
|
|
}
|
|
|
|
|
2010-02-07 21:48:13 +01:00
|
|
|
/*
|
|
|
|
* ReindexIsProcessingIndex
|
|
|
|
* True if index specified by OID is currently being reindexed,
|
|
|
|
* or should be treated as invalid because it is awaiting reindex.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
ReindexIsProcessingIndex(Oid indexOid)
|
|
|
|
{
|
|
|
|
return indexOid == currentlyReindexedIndex ||
|
|
|
|
list_member_oid(pendingReindexedIndexes, indexOid);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SetReindexProcessing
|
|
|
|
* Set flag that specified heap/index are being reindexed.
|
|
|
|
*
|
|
|
|
* NB: caller must use a PG_TRY block to ensure ResetReindexProcessing is done.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
SetReindexProcessing(Oid heapOid, Oid indexOid)
|
|
|
|
{
|
|
|
|
Assert(OidIsValid(heapOid) && OidIsValid(indexOid));
|
|
|
|
/* Reindexing is not re-entrant. */
|
|
|
|
if (OidIsValid(currentlyReindexedHeap))
|
|
|
|
elog(ERROR, "cannot reindex while reindexing");
|
|
|
|
currentlyReindexedHeap = heapOid;
|
|
|
|
currentlyReindexedIndex = indexOid;
|
2011-06-06 04:30:04 +02:00
|
|
|
/* Index is no longer "pending" reindex. */
|
|
|
|
RemoveReindexPending(indexOid);
|
2010-02-07 21:48:13 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ResetReindexProcessing
|
|
|
|
* Unset reindexing status.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ResetReindexProcessing(void)
|
|
|
|
{
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
/* This may be called in leader error path */
|
2010-02-07 21:48:13 +01:00
|
|
|
currentlyReindexedHeap = InvalidOid;
|
|
|
|
currentlyReindexedIndex = InvalidOid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SetReindexPending
|
|
|
|
* Mark the given indexes as pending reindex.
|
|
|
|
*
|
|
|
|
* NB: caller must use a PG_TRY block to ensure ResetReindexPending is done.
|
|
|
|
* Also, we assume that the current memory context stays valid throughout.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
SetReindexPending(List *indexes)
|
|
|
|
{
|
|
|
|
/* Reindexing is not re-entrant. */
|
|
|
|
if (pendingReindexedIndexes)
|
|
|
|
elog(ERROR, "cannot reindex while reindexing");
|
2018-01-19 13:48:44 +01:00
|
|
|
if (IsInParallelMode())
|
|
|
|
elog(ERROR, "cannot modify reindex state during a parallel operation");
|
2010-02-07 21:48:13 +01:00
|
|
|
pendingReindexedIndexes = list_copy(indexes);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RemoveReindexPending
|
|
|
|
* Remove the given index from the pending list.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
RemoveReindexPending(Oid indexOid)
|
|
|
|
{
|
2018-01-19 13:48:44 +01:00
|
|
|
if (IsInParallelMode())
|
|
|
|
elog(ERROR, "cannot modify reindex state during a parallel operation");
|
2010-02-07 21:48:13 +01:00
|
|
|
pendingReindexedIndexes = list_delete_oid(pendingReindexedIndexes,
|
|
|
|
indexOid);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ResetReindexPending
|
|
|
|
* Unset reindex-pending status.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ResetReindexPending(void)
|
|
|
|
{
|
2018-01-19 13:48:44 +01:00
|
|
|
if (IsInParallelMode())
|
|
|
|
elog(ERROR, "cannot modify reindex state during a parallel operation");
|
2010-02-07 21:48:13 +01:00
|
|
|
pendingReindexedIndexes = NIL;
|
|
|
|
}
|
2018-01-19 13:48:44 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* EstimateReindexStateSpace
|
|
|
|
* Estimate space needed to pass reindex state to parallel workers.
|
|
|
|
*/
|
|
|
|
extern Size
|
|
|
|
EstimateReindexStateSpace(void)
|
|
|
|
{
|
|
|
|
return offsetof(SerializedReindexState, pendingReindexedIndexes)
|
|
|
|
+ mul_size(sizeof(Oid), list_length(pendingReindexedIndexes));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SerializeReindexState
|
|
|
|
* Serialize reindex state for parallel workers.
|
|
|
|
*/
|
|
|
|
extern void
|
|
|
|
SerializeReindexState(Size maxsize, char *start_address)
|
|
|
|
{
|
|
|
|
SerializedReindexState *sistate = (SerializedReindexState *) start_address;
|
|
|
|
int c = 0;
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
|
|
sistate->currentlyReindexedHeap = currentlyReindexedHeap;
|
|
|
|
sistate->currentlyReindexedIndex = currentlyReindexedIndex;
|
|
|
|
sistate->numPendingReindexedIndexes = list_length(pendingReindexedIndexes);
|
|
|
|
foreach(lc, pendingReindexedIndexes)
|
|
|
|
sistate->pendingReindexedIndexes[c++] = lfirst_oid(lc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RestoreReindexState
|
|
|
|
* Restore reindex state in a parallel worker.
|
|
|
|
*/
|
|
|
|
extern void
|
|
|
|
RestoreReindexState(void *reindexstate)
|
|
|
|
{
|
|
|
|
SerializedReindexState *sistate = (SerializedReindexState *) reindexstate;
|
|
|
|
int c = 0;
|
|
|
|
MemoryContext oldcontext;
|
|
|
|
|
|
|
|
currentlyReindexedHeap = sistate->currentlyReindexedHeap;
|
|
|
|
currentlyReindexedIndex = sistate->currentlyReindexedIndex;
|
|
|
|
|
|
|
|
Assert(pendingReindexedIndexes == NIL);
|
|
|
|
oldcontext = MemoryContextSwitchTo(TopMemoryContext);
|
|
|
|
for (c = 0; c < sistate->numPendingReindexedIndexes; ++c)
|
|
|
|
pendingReindexedIndexes =
|
|
|
|
lappend_oid(pendingReindexedIndexes,
|
|
|
|
sistate->pendingReindexedIndexes[c]);
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
}
|