| blob | 650c049ffe756a2a8944d16220b613ac3c37c4d2 |
1 /*-------------------------------------------------------------------------
2 *
3 * index.c
4 * code to create and destroy POSTGRES index relations
5 *
6 * Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
7 * Portions Copyright (c) 1994, Regents of the University of California
8 *
9 *
10 * IDENTIFICATION
11 * $PostgreSQL$
12 *
13 *
14 * INTERFACE ROUTINES
15 * index_create() - Create a cataloged index relation
16 * index_drop() - Removes index relation from catalogs
17 * BuildIndexInfo() - Prepare to insert index tuples
18 * FormIndexDatum() - Construct datum vector for one index tuple
19 *
20 *-------------------------------------------------------------------------
21 */
24 #include <unistd.h>
67 /* state info for validate_index bulkdelete callback */
69 {
71 /* statistics (for debug purposes only): */
73 itups,
74 tups_inserted;
77 /* non-export function prototypes */
80 Oid accessMethodObjectId,
95 Relation indexRelation,
97 Snapshot snapshot,
102 /*
103 * ConstructTupleDescriptor
104 *
105 * Build an index tuple descriptor for a new index
106 */
107 static TupleDesc
110 Oid accessMethodObjectId,
112 {
115 HeapTuple amtuple;
116 Form_pg_am amform;
117 TupleDesc heapTupDesc;
118 TupleDesc indexTupDesc;
122 /* We need access to the index AM's pg_am tuple */
128 accessMethodObjectId);
131 /* ... and to the table's tuple descriptor */
135 /*
136 * allocate the new tuple descriptor
137 */
140 /*
141 * For simple index columns, we copy the pg_attribute row from the parent
142 * relation and modify it as necessary. For expressions we have to cons
143 * up a pg_attribute row the hard way.
144 */
146 {
149 HeapTuple tuple;
150 Form_pg_type typeTup;
151 Form_pg_opclass opclassTup;
152 Oid keyType;
155 {
156 /* Simple index column */
157 Form_pg_attribute from;
160 {
161 /*
162 * here we are indexing on a system attribute (-1...-n)
163 */
166 }
167 else
168 {
169 /*
170 * here we are indexing on a normal attribute (1...n)
171 */
175 }
177 /*
178 * now that we've determined the "from", let's copy the tuple desc
179 * data...
180 */
183 /*
184 * Fix the stuff that should not be the same as the underlying
185 * attr
186 */
195 }
196 else
197 {
198 /* Expressional index */
208 /*
209 * Make the attribute's name "pg_expresssion_nnn" (maybe think of
210 * something better later)
211 */
214 /*
215 * Lookup the expression type in pg_type for the type length etc.
216 */
225 /*
226 * Assign some of the attributes values. Leave the rest as 0.
227 */
241 /*
242 * Make sure the expression yields a type that's safe to store in
243 * an index. We need this defense because we have index opclasses
244 * for pseudo-types such as "record", and the actually stored type
245 * had better be safe; eg, a named composite type is okay, an
246 * anonymous record type is not. The test is the same as for
247 * whether a table column is of a safe type (which is why we
248 * needn't check for the non-expression case).
249 */
251 }
253 /*
254 * We do not yet have the correct relation OID for the index, so just
255 * set it invalid for now. InitializeAttributeOids() will fix it
256 * later.
257 */
260 /*
261 * Check the opclass and index AM to see if either provides a keytype
262 * (overriding the attribute type). Opclass takes precedence.
263 */
273 else
278 {
279 /* index value and heap value have different types */
295 }
296 }
301 }
303 /* ----------------------------------------------------------------
304 * InitializeAttributeOids
305 * ----------------------------------------------------------------
306 */
307 static void
310 Oid indexoid)
311 {
312 TupleDesc tupleDescriptor;
319 }
321 /* ----------------------------------------------------------------
322 * AppendAttributeTuples
323 * ----------------------------------------------------------------
324 */
325 static void
327 {
328 Relation pg_attribute;
329 CatalogIndexState indstate;
330 TupleDesc indexTupDesc;
333 /*
334 * open the attribute relation and its indexes
335 */
340 /*
341 * insert data from new index's tupdesc into pg_attribute
342 */
346 {
347 /*
348 * There used to be very grotty code here to set these fields, but I
349 * think it's unnecessary. They should be set already.
350 */
355 }
360 }
362 /* ----------------------------------------------------------------
363 * UpdateIndexRelation
364 *
365 * Construct and insert a new entry in the pg_index catalog
366 * ----------------------------------------------------------------
367 */
368 static void
370 Oid heapoid,
376 {
380 Datum exprsDatum;
381 Datum predDatum;
384 Relation pg_index;
385 HeapTuple tuple;
388 /*
389 * Copy the index key, opclass, and indoption info into arrays (should we
390 * make the caller pass them like this to start with?)
391 */
398 /*
399 * Convert the index expressions (if any) to a text datum
400 */
402 {
408 }
409 else
412 /*
413 * Convert the index predicate (if any) to a text datum. Note we convert
414 * implicit-AND format to normal explicit-AND for storage.
415 */
417 {
423 }
424 else
427 /*
428 * open the system catalog index relation
429 */
432 /*
433 * Build a pg_index tuple
434 */
445 /* we set isvalid and isready the same way */
459 /*
460 * insert the tuple into the pg_index catalog
461 */
464 /* update the indexes on pg_index */
467 /*
468 * close the relation and free the tuple
469 */
472 }
475 /*
476 * index_create
477 *
478 * heapRelationId: OID of table to build index on
479 * indexRelationName: what it say
480 * indexRelationId: normally, pass InvalidOid to let this routine
481 * generate an OID for the index. During bootstrap this may be
482 * nonzero to specify a preselected OID.
483 * indexInfo: same info executor uses to insert into the index
484 * accessMethodObjectId: OID of index AM to use
485 * tableSpaceId: OID of tablespace to use
486 * classObjectId: array of index opclass OIDs, one per index column
487 * coloptions: array of per-index-column indoption settings
488 * reloptions: AM-specific options
489 * isprimary: index is a PRIMARY KEY
490 * isconstraint: index is owned by a PRIMARY KEY or UNIQUE constraint
491 * allow_system_table_mods: allow table to be a system catalog
492 * skip_build: true to skip the index_build() step for the moment; caller
493 * must do it later (typically via reindex_index())
494 * concurrent: if true, do not lock the table against writers. The index
495 * will be marked "invalid" and the caller must take additional steps
496 * to fix it up.
497 *
498 * Returns OID of the created index.
499 */
500 Oid
503 Oid indexRelationId,
505 Oid accessMethodObjectId,
506 Oid tableSpaceId,
509 Datum reloptions,
515 {
516 Relation pg_class;
517 Relation heapRelation;
518 Relation indexRelation;
519 TupleDesc indexTupDesc;
521 Oid namespaceId;
526 /*
527 * Only SELECT ... FOR UPDATE/SHARE are allowed while doing a standard
528 * index build; but for concurrent builds we allow INSERT/UPDATE/DELETE
529 * (but not VACUUM).
530 */
534 /*
535 * The index will be in the same namespace as its parent table, and is
536 * shared across databases if and only if the parent is.
537 */
541 /*
542 * check parameters
543 */
554 /*
555 * concurrent index build on a system catalog is unsafe because we tend to
556 * release locks before committing in catalogs
557 */
564 /*
565 * We cannot allow indexing a shared relation after initdb (because
566 * there's no way to make the entry in other databases' pg_class).
567 */
573 /*
574 * Validate shared/non-shared tablespace (must check this before doing
575 * GetNewRelFileNode, to prevent Assert therein)
576 */
578 {
580 /* elog since this is not a user-facing error */
583 }
584 else
585 {
590 }
596 indexRelationName)));
598 /*
599 * construct tuple descriptor for index tuples
600 */
602 indexInfo,
603 accessMethodObjectId,
604 classObjectId);
606 /*
607 * Allocate an OID for the index, unless we were told what to use.
608 *
609 * The OID will be the relfilenode as well, so make sure it doesn't
610 * collide with either pg_class OIDs or existing physical files.
611 */
614 pg_class);
616 /*
617 * create the index relation's relcache entry and physical disk file. (If
618 * we fail further down, it's the smgr's responsibility to remove the disk
619 * file again.)
620 */
622 namespaceId,
623 tableSpaceId,
624 indexRelationId,
625 indexTupDesc,
626 RELKIND_INDEX,
627 shared_relation,
628 allow_system_table_mods);
632 /*
633 * Obtain exclusive lock on it. Although no other backends can see it
634 * until we commit, this prevents deadlock-risk complaints from lock
635 * manager in cases such as CLUSTER.
636 */
639 /*
640 * Fill in fields of the index's pg_class entry that are not set correctly
641 * by heap_create.
642 *
643 * XXX should have a cleaner way to create cataloged indexes
644 */
650 /*
651 * store index's pg_class entry
652 */
655 reloptions);
657 /* done with pg_class */
660 /*
661 * now update the object id's of all the attribute tuple forms in the
662 * index relation's tuple descriptor
663 */
666 indexRelationId);
668 /*
669 * append ATTRIBUTE tuples for the index
670 */
673 /* ----------------
674 * update pg_index
675 * (append INDEX tuple)
676 *
677 * Note that this stows away a representation of "predicate".
678 * (Or, could define a rule to maintain the predicate) --Nels, Feb '92
679 * ----------------
680 */
684 /*
685 * Register constraint and dependencies for the index.
686 *
687 * If the index is from a CONSTRAINT clause, construct a pg_constraint
688 * entry. The index is then linked to the constraint, which in turn is
689 * linked to the table. If it's not a CONSTRAINT, make the dependency
690 * directly on the table.
691 *
692 * We don't need a dependency on the namespace, because there'll be an
693 * indirect dependency via our parent table.
694 *
695 * During bootstrap we can't register any dependencies, and we don't try
696 * to make a constraint either.
697 */
699 {
700 ObjectAddress myself,
701 referenced;
708 {
710 Oid conOid;
716 else
717 {
720 }
722 /* Shouldn't have any expressions */
727 namespaceId,
728 constraintType,
731 heapRelationId,
736 NULL,
737 NULL,
738 NULL,
739 NULL,
746 NULL,
747 NULL,
756 }
757 else
758 {
761 /* Create auto dependencies on simply-referenced columns */
763 {
765 {
773 }
774 }
776 /*
777 * It's possible for an index to not depend on any columns of the
778 * table at all, in which case we need to give it a dependency on
779 * the table as a whole; else it won't get dropped when the table
780 * is dropped. This edge case is not totally useless; for
781 * example, a unique index on a constant expression can serve to
782 * prevent a table from containing more than one row.
783 */
787 {
793 }
794 }
796 /* Store dependency on operator classes */
798 {
804 }
806 /* Store dependencies on anything mentioned in index expressions */
808 {
811 heapRelationId,
812 DEPENDENCY_NORMAL,
813 DEPENDENCY_AUTO);
814 }
816 /* Store dependencies on anything mentioned in predicate */
818 {
821 heapRelationId,
822 DEPENDENCY_NORMAL,
823 DEPENDENCY_AUTO);
824 }
825 }
827 /*
828 * Advance the command counter so that we can see the newly-entered
829 * catalog tuples for the index.
830 */
833 /*
834 * In bootstrap mode, we have to fill in the index strategy structure with
835 * information from the catalogs. If we aren't bootstrapping, then the
836 * relcache entry has already been rebuilt thanks to sinval update during
837 * CommandCounterIncrement.
838 */
841 else
844 /*
845 * If this is bootstrap (initdb) time, then we don't actually fill in the
846 * index yet. We'll be creating more indexes and classes later, so we
847 * delay filling them in until just before we're done with bootstrapping.
848 * Similarly, if the caller specified skip_build then filling the index is
849 * delayed till later (ALTER TABLE can save work in some cases with this).
850 * Otherwise, we call the AM routine that constructs the index.
851 */
853 {
855 }
857 {
858 /*
859 * Caller is responsible for filling the index later on. However,
860 * we'd better make sure that the heap relation is correctly marked as
861 * having an index.
862 */
865 isprimary,
866 InvalidOid,
868 /* Make the above update visible */
870 }
871 else
872 {
874 }
876 /*
877 * Close the heap and index; but we keep the locks that we acquired above
878 * until end of transaction.
879 */
884 }
886 /*
887 * index_drop
888 *
889 * NOTE: this routine should now only be called through performDeletion(),
890 * else associated dependencies won't be cleaned up.
891 */
892 void
894 {
895 Oid heapId;
896 Relation userHeapRelation;
897 Relation userIndexRelation;
898 Relation indexRelation;
899 HeapTuple tuple;
902 /*
903 * To drop an index safely, we must grab exclusive lock on its parent
904 * table. Exclusive lock on the index alone is insufficient because
905 * another backend might be about to execute a query on the parent table.
906 * If it relies on a previously cached list of index OIDs, then it could
907 * attempt to access the just-dropped index. We must therefore take a
908 * table lock strong enough to prevent all queries on the table from
909 * proceeding until we commit and send out a shared-cache-inval notice
910 * that will make them update their index lists.
911 */
917 /*
918 * Schedule physical removal of the files
919 */
922 /*
923 * Close and flush the index's relcache entry, to ensure relcache doesn't
924 * try to rebuild it while we're deleting catalog entries. We keep the
925 * lock though.
926 */
931 /*
932 * fix INDEX relation, and check for expressional index
933 */
949 /*
950 * if it has any expression columns, we might have stored statistics about
951 * them.
952 */
956 /*
957 * fix ATTRIBUTE relation
958 */
961 /*
962 * fix RELATION relation
963 */
966 /*
967 * We are presently too lazy to attempt to compute the new correct value
968 * of relhasindex (the next VACUUM will fix it if necessary). So there is
969 * no need to update the pg_class tuple for the owning relation. But we
970 * must send out a shared-cache-inval notice on the owning relation to
971 * ensure other backends update their relcache lists of indexes.
972 */
975 /*
976 * Close owning rel, but keep lock
977 */
979 }
981 /* ----------------------------------------------------------------
982 * index_build support
983 * ----------------------------------------------------------------
984 */
986 /* ----------------
987 * BuildIndexInfo
988 * Construct an IndexInfo record for an open index
989 *
990 * IndexInfo stores the information about the index that's needed by
991 * FormIndexDatum, which is used for both index_build() and later insertion
992 * of individual index tuples. Normally we build an IndexInfo for an index
993 * just once per command, and then use it for (potentially) many tuples.
994 * ----------------
995 */
996 IndexInfo *
998 {
1004 /* check the number of keys, and copy attr numbers into the IndexInfo */
1013 /* fetch any expressions needed for expressional indexes */
1017 /* fetch index predicate if any */
1021 /* other info */
1025 /* initialize index-build state to default */
1030 }
1032 /* ----------------
1033 * FormIndexDatum
1034 * Construct values[] and isnull[] arrays for a new index tuple.
1035 *
1036 * indexInfo Info about the index
1037 * slot Heap tuple for which we must prepare an index entry
1038 * estate executor state for evaluating any index expressions
1039 * values Array of index Datums (output area)
1040 * isnull Array of is-null indicators (output area)
1041 *
1042 * When there are no index expressions, estate may be NULL. Otherwise it
1043 * must be supplied, *and* the ecxt_scantuple slot of its per-tuple expr
1044 * context must point to the heap tuple passed in.
1045 *
1046 * Notice we don't actually call index_form_tuple() here; we just prepare
1047 * its input arrays values[] and isnull[]. This is because the index AM
1048 * may wish to alter the data before storage.
1049 * ----------------
1050 */
1051 void
1057 {
1063 {
1064 /* First time through, set up expression evaluation state */
1067 estate);
1068 /* Check caller has set up context correctly */
1070 }
1074 {
1076 Datum iDatum;
1080 {
1081 /*
1082 * Plain index column; get the value we need directly from the
1083 * heap tuple.
1084 */
1086 }
1087 else
1088 {
1089 /*
1090 * Index expression --- need to evaluate it.
1091 */
1097 NULL);
1099 }
1102 }
1106 }
1109 /*
1110 * index_update_stats --- update pg_class entry after CREATE INDEX or REINDEX
1111 *
1112 * This routine updates the pg_class row of either an index or its parent
1113 * relation after CREATE INDEX or REINDEX. Its rather bizarre API is designed
1114 * to ensure we can do all the necessary work in just one update.
1115 *
1116 * hasindex: set relhasindex to this value
1117 * isprimary: if true, set relhaspkey true; else no change
1118 * reltoastidxid: if not InvalidOid, set reltoastidxid to this value;
1119 * else no change
1120 * reltuples: set reltuples to this value
1121 *
1122 * relpages is also updated (using RelationGetNumberOfBlocks()).
1123 *
1124 * NOTE: an important side-effect of this operation is that an SI invalidation
1125 * message is sent out to all backends --- including me --- causing relcache
1126 * entries to be flushed or updated with the new data. This must happen even
1127 * if we find that no change is needed in the pg_class row. When updating
1128 * a heap entry, this ensures that other backends find out about the new
1129 * index. When updating an index, it's important because some index AMs
1130 * expect a relcache flush to occur after REINDEX.
1131 */
1132 static void
1135 {
1138 Relation pg_class;
1139 HeapTuple tuple;
1140 Form_pg_class rd_rel;
1143 /*
1144 * We always update the pg_class row using a non-transactional,
1145 * overwrite-in-place update. There are several reasons for this:
1146 *
1147 * 1. In bootstrap mode, we have no choice --- UPDATE wouldn't work.
1148 *
1149 * 2. We could be reindexing pg_class itself, in which case we can't move
1150 * its pg_class row because CatalogUpdateIndexes might not know about all
1151 * the indexes yet (see reindex_relation).
1152 *
1153 * 3. Because we execute CREATE INDEX with just share lock on the parent
1154 * rel (to allow concurrent index creations), an ordinary update could
1155 * suffer a tuple-concurrently-updated failure against another CREATE
1156 * INDEX committing at about the same time. We can avoid that by having
1157 * them both do nontransactional updates (we assume they will both be
1158 * trying to change the pg_class row to the same thing, so it doesn't
1159 * matter which goes first).
1160 *
1161 * 4. Even with just a single CREATE INDEX, there's a risk factor because
1162 * someone else might be trying to open the rel while we commit, and this
1163 * creates a race condition as to whether he will see both or neither of
1164 * the pg_class row versions as valid. Again, a non-transactional update
1165 * avoids the risk. It is indeterminate which state of the row the other
1166 * process will see, but it doesn't matter (if he's only taking
1167 * AccessShareLock, then it's not critical that he see relhasindex true).
1168 *
1169 * It is safe to use a non-transactional update even though our
1170 * transaction could still fail before committing. Setting relhasindex
1171 * true is safe even if there are no indexes (VACUUM will eventually fix
1172 * it), and of course the relpages and reltuples counts are correct (or at
1173 * least more so than the old values) regardless.
1174 */
1178 /*
1179 * Make a copy of the tuple to update. Normally we use the syscache, but
1180 * we can't rely on that during bootstrap or while reindexing pg_class
1181 * itself.
1182 */
1185 {
1186 /* don't assume syscache will work */
1187 HeapScanDesc pg_class_scan;
1191 ObjectIdAttributeNumber,
1199 }
1200 else
1201 {
1202 /* normal case, use syscache */
1206 }
1212 /* Apply required updates, if any, to copied tuple */
1216 {
1219 }
1221 {
1223 {
1226 }
1227 }
1229 {
1232 {
1235 }
1236 }
1238 {
1241 }
1243 {
1246 }
1248 /*
1249 * If anything changed, write out the tuple
1250 */
1252 {
1254 /* the above sends a cache inval message */
1255 }
1256 else
1257 {
1258 /* no need to change tuple, but force relcache inval anyway */
1260 }
1265 }
1267 /*
1268 * setNewRelfilenode - assign a new relfilenode value to the relation
1269 *
1270 * Caller must already hold exclusive lock on the relation.
1271 *
1272 * The relation is marked with relfrozenxid=freezeXid (InvalidTransactionId
1273 * must be passed for indexes)
1274 */
1275 void
1277 {
1278 Oid newrelfilenode;
1279 RelFileNode newrnode;
1280 Relation pg_class;
1281 HeapTuple tuple;
1282 Form_pg_class rd_rel;
1284 /* Can't change relfilenode for nailed tables (indexes ok though) */
1287 /* Can't change for shared tables or indexes */
1289 /* Indexes must have Invalid frozenxid; other relations must not */
1294 /* Allocate a new relfilenode */
1297 NULL);
1299 /*
1300 * Find the pg_class tuple for the given relation. This is not used
1301 * during bootstrap, so okay to use heap_update always.
1302 */
1313 /*
1314 * ... and create storage for corresponding forks in the new relfilenode.
1315 *
1316 * NOTE: any conflict in relfilenode value will be caught here
1317 */
1321 /*
1322 * Create the main fork, like heap_create() does, and drop the old
1323 * storage.
1324 */
1329 /* update the pg_class row */
1341 /* Make sure the relfilenode change is visible */
1344 /* Mark the rel as having a new relfilenode in current transaction */
1346 }
1349 /*
1350 * index_build - invoke access-method-specific index build procedure
1351 *
1352 * On entry, the index's catalog entries are valid, and its physical disk
1353 * file has been created but is empty. We call the AM-specific build
1354 * procedure to fill in the index contents. We then update the pg_class
1355 * entries of the index and heap relation as needed, using statistics
1356 * returned by ambuild as well as data passed by the caller.
1357 *
1358 * Note: when reindexing an existing index, isprimary can be false;
1359 * the index is already properly marked and need not be re-marked.
1360 *
1361 * Note: before Postgres 8.2, the passed-in heap and index Relations
1362 * were automatically closed by this routine. This is no longer the case.
1363 * The caller opened 'em, and the caller should close 'em.
1364 */
1365 void
1367 Relation indexRelation,
1370 {
1371 RegProcedure procedure;
1373 Oid save_userid;
1376 /*
1377 * sanity checks
1378 */
1385 /*
1386 * Switch to the table owner's userid, so that any index functions are
1387 * run as that user.
1388 */
1392 /*
1393 * Call the access method's build procedure
1394 */
1402 /* Restore userid */
1405 /*
1406 * If we found any potentially broken HOT chains, mark the index as not
1407 * being usable until the current transaction is below the event horizon.
1408 * See src/backend/access/heap/README.HOT for discussion.
1409 */
1411 {
1413 Relation pg_index;
1414 HeapTuple indexTuple;
1415 Form_pg_index indexForm;
1432 }
1434 /*
1435 * Update heap and index pg_class rows
1436 */
1439 isprimary,
1447 InvalidOid,
1450 /* Make the updated versions visible */
1452 }
1455 /*
1456 * IndexBuildHeapScan - scan the heap relation to find tuples to be indexed
1457 *
1458 * This is called back from an access-method-specific index build procedure
1459 * after the AM has done whatever setup it needs. The parent heap relation
1460 * is scanned to find tuples that should be entered into the index. Each
1461 * such tuple is passed to the AM's callback routine, which does the right
1462 * things to add it to the new index. After we return, the AM's index
1463 * build procedure does whatever cleanup is needed; in particular, it should
1464 * close the heap and index relations.
1465 *
1466 * The total count of heap tuples is returned. This is for updating pg_class
1467 * statistics. (It's annoying not to be able to do that here, but we can't
1468 * do it until after the relation is closed.) Note that the index AM itself
1469 * must keep track of the number of index tuples; we don't do so here because
1470 * the AM might reject some of the tuples for its own reasons, such as being
1471 * unable to store NULLs.
1472 *
1473 * A side effect is to set indexInfo->ii_BrokenHotChain to true if we detect
1474 * any potentially broken HOT chains. Currently, we set this if there are
1475 * any RECENTLY_DEAD entries in a HOT chain, without trying very hard to
1476 * detect whether they're really incompatible with the chain tip.
1477 */
1478 double
1480 Relation indexRelation,
1483 IndexBuildCallback callback,
1485 {
1486 HeapScanDesc scan;
1487 HeapTuple heapTuple;
1495 Snapshot snapshot;
1496 TransactionId OldestXmin;
1500 /*
1501 * sanity checks
1502 */
1505 /*
1506 * Need an EState for evaluation of index expressions and partial-index
1507 * predicates. Also a slot to hold the current tuple.
1508 */
1513 /* Arrange for econtext's scan tuple to be the tuple under test */
1516 /* Set up execution state for predicate, if any. */
1519 estate);
1521 /*
1522 * Prepare for scan of the base relation. In a normal index build, we use
1523 * SnapshotAny because we must retrieve all tuples and do our own time
1524 * qual checks (because we have to index RECENTLY_DEAD tuples). In a
1525 * concurrent build, we take a regular MVCC snapshot and index whatever's
1526 * live according to that. During bootstrap we just use SnapshotNow.
1527 */
1529 {
1532 }
1534 {
1537 }
1538 else
1539 {
1541 /* okay to ignore lazy VACUUMs here */
1543 }
1554 /*
1555 * Scan all tuples in the base relation.
1556 */
1558 {
1563 /*
1564 * When dealing with a HOT-chain of updated tuples, we want to index
1565 * the values of the live tuple (if any), but index it under the TID
1566 * of the chain's root tuple. This approach is necessary to preserve
1567 * the HOT-chain structure in the heap. So we need to be able to find
1568 * the root item offset for every tuple that's in a HOT-chain. When
1569 * first reaching a new page of the relation, call
1570 * heap_get_root_tuples() to build a map of root item offsets on the
1571 * page.
1572 *
1573 * It might look unsafe to use this information across buffer
1574 * lock/unlock. However, we hold ShareLock on the table so no
1575 * ordinary insert/update/delete should occur; and we hold pin on the
1576 * buffer continuously while visiting the page, so no pruning
1577 * operation can occur either.
1578 *
1579 * Note the implied assumption that there is no more than one live
1580 * tuple per HOT-chain ...
1581 */
1583 {
1591 }
1594 {
1595 /* do our own time qual check */
1598 recheck:
1600 /*
1601 * We could possibly get away with not locking the buffer here,
1602 * since caller should hold ShareLock on the relation, but let's
1603 * be conservative about it. (This remark is still correct even
1604 * with HOT-pruning: our pin on the buffer prevents pruning.)
1605 */
1610 {
1612 /* Definitely dead, we can ignore it */
1617 /* Normal case, index and unique-check it */
1623 /*
1624 * If tuple is recently deleted then we must index it
1625 * anyway to preserve MVCC semantics. (Pre-existing
1626 * transactions could try to use the index after we finish
1627 * building it, and may need to see such tuples.)
1628 *
1629 * However, if it was HOT-updated then we must only index
1630 * the live tuple at the end of the HOT-chain. Since this
1631 * breaks semantics for pre-existing snapshots, mark the
1632 * index as unusable for them.
1633 *
1634 * If we've already decided that the index will be unsafe
1635 * for old snapshots, we may as well stop indexing
1636 * recently-dead tuples, since there's no longer any
1637 * point.
1638 */
1640 {
1642 /* mark the index as unsafe for old snapshots */
1644 }
1647 else
1649 /* In any case, exclude the tuple from unique-checking */
1654 /*
1655 * Since caller should hold ShareLock or better, we should
1656 * not see any tuples inserted by open transactions ---
1657 * unless it's our own transaction. (Consider INSERT
1658 * followed by CREATE INDEX within a transaction.) An
1659 * exception occurs when reindexing a system catalog,
1660 * because we often release lock on system catalogs before
1661 * committing. In that case we wait for the inserting
1662 * transaction to finish and check again. (We could do
1663 * that on user tables too, but since the case is not
1664 * expected it seems better to throw an error.)
1665 */
1668 {
1671 else
1672 {
1673 /*
1674 * Must drop the lock on the buffer before we wait
1675 */
1681 }
1682 }
1684 /*
1685 * We must index such tuples, since if the index build
1686 * commits then they're good.
1687 */
1693 /*
1694 * Since caller should hold ShareLock or better, we should
1695 * not see any tuples deleted by open transactions ---
1696 * unless it's our own transaction. (Consider DELETE
1697 * followed by CREATE INDEX within a transaction.) An
1698 * exception occurs when reindexing a system catalog,
1699 * because we often release lock on system catalogs before
1700 * committing. In that case we wait for the deleting
1701 * transaction to finish and check again. (We could do
1702 * that on user tables too, but since the case is not
1703 * expected it seems better to throw an error.)
1704 */
1708 {
1711 else
1712 {
1713 /*
1714 * Must drop the lock on the buffer before we wait
1715 */
1721 }
1722 }
1724 /*
1725 * Otherwise, we have to treat these tuples just like
1726 * RECENTLY_DELETED ones.
1727 */
1729 {
1731 /* mark the index as unsafe for old snapshots */
1733 }
1736 else
1738 /* In any case, exclude the tuple from unique-checking */
1745 }
1751 }
1752 else
1753 {
1754 /* heap_getnext did the time qual check */
1756 }
1762 /* Set up for predicate or expression evaluation */
1765 /*
1766 * In a partial index, discard tuples that don't satisfy the
1767 * predicate.
1768 */
1770 {
1773 }
1775 /*
1776 * For the current heap tuple, extract all the attributes we use in
1777 * this index, and note which are null. This also performs evaluation
1778 * of any expressions needed.
1779 */
1781 slot,
1782 estate,
1783 values,
1784 isnull);
1786 /*
1787 * You'd think we should go ahead and build the index tuple here, but
1788 * some index AMs want to do further processing on the data first. So
1789 * pass the values[] and isnull[] arrays, instead.
1790 */
1793 {
1794 /*
1795 * For a heap-only tuple, pretend its TID is that of the root. See
1796 * src/backend/access/heap/README.HOT for discussion.
1797 */
1798 HeapTupleData rootTuple;
1799 OffsetNumber offnum;
1809 /* Call the AM's callback routine to process the tuple */
1811 callback_state);
1812 }
1813 else
1814 {
1815 /* Call the AM's callback routine to process the tuple */
1817 callback_state);
1818 }
1819 }
1823 /* we can now forget our snapshot, if set */
1831 /* These may have been pointing to the now-gone estate */
1836 }
1839 /*
1840 * validate_index - support code for concurrent index builds
1841 *
1842 * We do a concurrent index build by first inserting the catalog entry for the
1843 * index via index_create(), marking it not indisready and not indisvalid.
1844 * Then we commit our transaction and start a new one, then we wait for all
1845 * transactions that could have been modifying the table to terminate. Now
1846 * we know that any subsequently-started transactions will see the index and
1847 * honor its constraints on HOT updates; so while existing HOT-chains might
1848 * be broken with respect to the index, no currently live tuple will have an
1849 * incompatible HOT update done to it. We now build the index normally via
1850 * index_build(), while holding a weak lock that allows concurrent
1851 * insert/update/delete. Also, we index only tuples that are valid
1852 * as of the start of the scan (see IndexBuildHeapScan), whereas a normal
1853 * build takes care to include recently-dead tuples. This is OK because
1854 * we won't mark the index valid until all transactions that might be able
1855 * to see those tuples are gone. The reason for doing that is to avoid
1856 * bogus unique-index failures due to concurrent UPDATEs (we might see
1857 * different versions of the same row as being valid when we pass over them,
1858 * if we used HeapTupleSatisfiesVacuum). This leaves us with an index that
1859 * does not contain any tuples added to the table while we built the index.
1860 *
1861 * Next, we mark the index "indisready" (but still not "indisvalid") and
1862 * commit the second transaction and start a third. Again we wait for all
1863 * transactions that could have been modifying the table to terminate. Now
1864 * we know that any subsequently-started transactions will see the index and
1865 * insert their new tuples into it. We then take a new reference snapshot
1866 * which is passed to validate_index(). Any tuples that are valid according
1867 * to this snap, but are not in the index, must be added to the index.
1868 * (Any tuples committed live after the snap will be inserted into the
1869 * index by their originating transaction. Any tuples committed dead before
1870 * the snap need not be indexed, because we will wait out all transactions
1871 * that might care about them before we mark the index valid.)
1872 *
1873 * validate_index() works by first gathering all the TIDs currently in the
1874 * index, using a bulkdelete callback that just stores the TIDs and doesn't
1875 * ever say "delete it". (This should be faster than a plain indexscan;
1876 * also, not all index AMs support full-index indexscan.) Then we sort the
1877 * TIDs, and finally scan the table doing a "merge join" against the TID list
1878 * to see which tuples are missing from the index. Thus we will ensure that
1879 * all tuples valid according to the reference snapshot are in the index.
1880 *
1881 * Building a unique index this way is tricky: we might try to insert a
1882 * tuple that is already dead or is in process of being deleted, and we
1883 * mustn't have a uniqueness failure against an updated version of the same
1884 * row. We could try to check the tuple to see if it's already dead and tell
1885 * index_insert() not to do the uniqueness check, but that still leaves us
1886 * with a race condition against an in-progress update. To handle that,
1887 * we expect the index AM to recheck liveness of the to-be-inserted tuple
1888 * before it declares a uniqueness error.
1889 *
1890 * After completing validate_index(), we wait until all transactions that
1891 * were alive at the time of the reference snapshot are gone; this is
1892 * necessary to be sure there are none left with a serializable snapshot
1893 * older than the reference (and hence possibly able to see tuples we did
1894 * not index). Then we mark the index "indisvalid" and commit. Subsequent
1895 * transactions will be able to use it for queries.
1896 *
1897 * Doing two full table scans is a brute-force strategy. We could try to be
1898 * cleverer, eg storing new tuples in a special area of the table (perhaps
1899 * making the table append-only by setting use_fsm). However that would
1900 * add yet more locking issues.
1901 */
1902 void
1904 {
1905 Relation heapRelation,
1906 indexRelation;
1908 IndexVacuumInfo ivinfo;
1909 v_i_state state;
1910 Oid save_userid;
1913 /* Open and lock the parent heap relation */
1915 /* And the target index relation */
1918 /*
1919 * Fetch info needed for index_insert. (You might think this should be
1920 * passed in from DefineIndex, but its copy is long gone due to having
1921 * been built in a previous transaction.)
1922 */
1925 /* mark build is concurrent just for consistency */
1928 /*
1929 * Switch to the table owner's userid, so that any index functions are
1930 * run as that user.
1931 */
1935 /*
1936 * Scan the index and gather up all the TIDs into a tuplesort object.
1937 */
1947 maintenance_work_mem,
1954 /* Execute the sort */
1957 /*
1958 * Now scan the heap and "merge" it with the index
1959 */
1961 indexRelation,
1962 indexInfo,
1963 snapshot,
1966 /* Done with tuplesort object */
1973 /* Restore userid */
1976 /* Close rels, but keep locks */
1979 }
1981 /*
1982 * validate_index_callback - bulkdelete callback to collect the index TIDs
1983 */
1984 static bool
1986 {
1992 }
1994 /*
1995 * validate_index_heapscan - second table scan for concurrent index build
1996 *
1997 * This has much code in common with IndexBuildHeapScan, but it's enough
1998 * different that it seems cleaner to have two routines not one.
1999 */
2000 static void
2002 Relation indexRelation,
2004 Snapshot snapshot,
2006 {
2007 HeapScanDesc scan;
2008 HeapTuple heapTuple;
2019 /* state variables for the merge */
2023 /*
2024 * sanity checks
2025 */
2028 /*
2029 * Need an EState for evaluation of index expressions and partial-index
2030 * predicates. Also a slot to hold the current tuple.
2031 */
2036 /* Arrange for econtext's scan tuple to be the tuple under test */
2039 /* Set up execution state for predicate, if any. */
2042 estate);
2044 /*
2045 * Prepare for scan of the base relation. We need just those tuples
2046 * satisfying the passed-in reference snapshot. We must disable syncscan
2047 * here, because it's critical that we read from block zero forward to
2048 * match the sorted TIDs.
2049 */
2057 /*
2058 * Scan all tuples matching the snapshot.
2059 */
2061 {
2063 ItemPointerData rootTuple;
2064 OffsetNumber root_offnum;
2070 /*
2071 * As commented in IndexBuildHeapScan, we should index heap-only
2072 * tuples under the TIDs of their root tuples; so when we advance onto
2073 * a new heap page, build a map of root item offsets on the page.
2074 *
2075 * This complicates merging against the tuplesort output: we will
2076 * visit the live tuples in order by their offsets, but the root
2077 * offsets that we need to compare against the index contents might be
2078 * ordered differently. So we might have to "look back" within the
2079 * tuplesort output, but only within the current page. We handle that
2080 * by keeping a bool array in_index[] showing all the
2081 * already-passed-over tuplesort output TIDs of the current page. We
2082 * clear that array here, when advancing onto a new heap page.
2083 */
2085 {
2095 }
2097 /* Convert actual tuple TID to root TID */
2102 {
2106 }
2108 /*
2109 * "merge" by skipping through the index tuples until we find or pass
2110 * the current root tuple.
2111 */
2115 {
2116 Datum ts_val;
2120 {
2121 /*
2122 * Remember index items seen earlier on the current heap page
2123 */
2127 }
2133 }
2135 /*
2136 * If the tuplesort has overshot *and* we didn't see a match earlier,
2137 * then this tuple is missing from the index, so insert it.
2138 */
2142 {
2145 /* Set up for predicate or expression evaluation */
2148 /*
2149 * In a partial index, discard tuples that don't satisfy the
2150 * predicate.
2151 */
2153 {
2156 }
2158 /*
2159 * For the current heap tuple, extract all the attributes we use
2160 * in this index, and note which are null. This also performs
2161 * evaluation of any expressions needed.
2162 */
2164 slot,
2165 estate,
2166 values,
2167 isnull);
2169 /*
2170 * You'd think we should go ahead and build the index tuple here,
2171 * but some index AMs want to do further processing on the data
2172 * first. So pass the values[] and isnull[] arrays, instead.
2173 */
2175 /*
2176 * If the tuple is already committed dead, you might think we
2177 * could suppress uniqueness checking, but this is no longer true
2178 * in the presence of HOT, because the insert is actually a proxy
2179 * for a uniqueness check on the whole HOT-chain. That is, the
2180 * tuple we have here could be dead because it was already
2181 * HOT-updated, and if so the updating transaction will not have
2182 * thought it should insert index entries. The index AM will
2183 * check the whole HOT-chain and correctly detect a conflict if
2184 * there is one.
2185 */
2188 values,
2189 isnull,
2191 heapRelation,
2195 }
2196 }
2204 /* These may have been pointing to the now-gone estate */
2207 }
2210 /*
2211 * IndexGetRelation: given an index's relation OID, get the OID of the
2212 * relation it is an index on. Uses the system cache.
2213 */
2214 static Oid
2216 {
2217 HeapTuple tuple;
2218 Form_pg_index index;
2219 Oid result;
2232 }
2234 /*
2235 * reindex_index - This routine is used to recreate a single index
2236 */
2237 void
2239 {
2240 Relation iRel,
2241 heapRelation,
2242 pg_index;
2243 Oid heapId;
2246 HeapTuple indexTuple;
2247 Form_pg_index indexForm;
2249 /*
2250 * Open and lock the parent heap relation. ShareLock is sufficient since
2251 * we only need to be sure no schema or data changes are going on.
2252 */
2256 /*
2257 * Open the target index relation and get an exclusive lock on it, to
2258 * ensure that no one else is touching this particular index.
2259 */
2262 /*
2263 * Don't allow reindex on temp tables of other backends ... their local
2264 * buffer manager is not going to cope.
2265 */
2271 /*
2272 * Also check for active uses of the index in the current transaction;
2273 * we don't want to reindex underneath an open indexscan.
2274 */
2277 /*
2278 * If it's a shared index, we must do inplace processing (because we have
2279 * no way to update relfilenode in other databases). Otherwise we can do
2280 * it the normal transaction-safe way.
2281 *
2282 * Since inplace processing isn't crash-safe, we only allow it in a
2283 * standalone backend. (In the REINDEX TABLE and REINDEX DATABASE cases,
2284 * the caller should have detected this.)
2285 */
2295 {
2296 /* Suppress use of the target index while rebuilding it */
2299 /* Fetch info needed for index_build */
2303 {
2304 /*
2305 * Truncate the actual file (and discard buffers).
2306 */
2308 }
2309 else
2310 {
2311 /*
2312 * We'll build a new physical relation for the index.
2313 */
2315 }
2317 /* Initialize the index and rebuild */
2318 /* Note: we do not need to re-establish pkey setting */
2320 }
2322 {
2323 /* Make sure flag gets cleared on error exit */
2326 }
2330 /*
2331 * If the index is marked invalid or not ready (ie, it's from a failed
2332 * CREATE INDEX CONCURRENTLY), we can now mark it valid. This allows
2333 * REINDEX to be used to clean up in such cases.
2334 *
2335 * We can also reset indcheckxmin, because we have now done a
2336 * non-concurrent index build, *except* in the case where index_build
2337 * found some still-broken HOT chains.
2338 */
2350 {
2357 }
2360 /* Close rels, but keep locks */
2363 }
2365 /*
2366 * reindex_relation - This routine is used to recreate all indexes
2367 * of a relation (and optionally its toast relation too, if any).
2368 *
2369 * Returns true if any indexes were rebuilt. Note that a
2370 * CommandCounterIncrement will occur after each index rebuild.
2371 */
2372 bool
2374 {
2375 Relation rel;
2376 Oid toast_relid;
2383 /*
2384 * Open and lock the relation. ShareLock is sufficient since we only need
2385 * to prevent schema and data changes in it.
2386 */
2391 /*
2392 * Get the list of index OIDs for this relation. (We trust to the
2393 * relcache to get this with a sequential scan if ignoring system
2394 * indexes.)
2395 */
2398 /*
2399 * reindex_index will attempt to update the pg_class rows for the relation
2400 * and index. If we are processing pg_class itself, we want to make sure
2401 * that the updates do not try to insert index entries into indexes we
2402 * have not processed yet. (When we are trying to recover from corrupted
2403 * indexes, that could easily cause a crash.) We can accomplish this
2404 * because CatalogUpdateIndexes will use the relcache's index list to know
2405 * which indexes to update. We just force the index list to be only the
2406 * stuff we've processed.
2407 *
2408 * It is okay to not insert entries into the indexes we have not processed
2409 * yet because all of this is transaction-safe. If we fail partway
2410 * through, the updated rows are dead and it doesn't matter whether they
2411 * have index entries. Also, a new pg_class index will be created with an
2412 * entry for its own pg_class row because we do setNewRelfilenode() before
2413 * we do index_build().
2414 *
2415 * Note that we also clear pg_class's rd_oidindex until the loop is done,
2416 * so that that index can't be accessed either. This means we cannot
2417 * safely generate new relation OIDs while in the loop; shouldn't be a
2418 * problem.
2419 */
2422 /* Ensure rd_indexattr is valid; see comments for RelationSetIndexList */
2426 /* Reindex all the indexes. */
2429 {
2441 }
2446 /*
2447 * Close rel, but continue to hold the lock.
2448 */
2453 /*
2454 * If the relation has a secondary toast rel, reindex that too while we
2455 * still hold the lock on the master table.
2456 */
2461 }