| blob | 469b63a83be29ca98bea8a0a326e26c0384d5b74 |
1 /*-------------------------------------------------------------------------
2 *
3 * heapam.c
4 * heap access method code
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 * relation_open - open any relation by relation OID
16 * relation_openrv - open any relation specified by a RangeVar
17 * relation_close - close any relation
18 * heap_open - open a heap relation by relation OID
19 * heap_openrv - open a heap relation specified by a RangeVar
20 * heap_close - (now just a macro for relation_close)
21 * heap_beginscan - begin relation scan
22 * heap_rescan - restart a relation scan
23 * heap_endscan - end relation scan
24 * heap_getnext - retrieve next tuple in scan
25 * heap_fetch - retrieve tuple with given tid
26 * heap_insert - insert tuple into a relation
27 * heap_delete - delete a tuple from a relation
28 * heap_update - replace a tuple in a relation with another tuple
29 * heap_markpos - mark scan position
30 * heap_restrpos - restore position to marked location
31 * heap_sync - sync heap, for when no WAL has been written
32 *
33 * NOTES
34 * This file contains the heap_ routines which implement
35 * the POSTGRES heap access method used for all POSTGRES
36 * relations.
37 *
38 *-------------------------------------------------------------------------
39 */
71 /* GUC variable */
76 Snapshot snapshot,
86 /* ----------------------------------------------------------------
87 * heap support routines
88 * ----------------------------------------------------------------
89 */
91 /* ----------------
92 * initscan - scan code common to heap_beginscan and heap_rescan
93 * ----------------
94 */
95 static void
97 {
101 /*
102 * Determine the number of blocks we have to scan.
103 *
104 * It is sufficient to do this once at scan start, since any tuples added
105 * while the scan is in progress will be invisible to my snapshot anyway.
106 * (That is not true when using a non-MVCC snapshot. However, we couldn't
107 * guarantee to return tuples added after scan start anyway, since they
108 * might go into pages we already scanned. To guarantee consistent
109 * results for a non-MVCC snapshot, the caller must hold some higher-level
110 * lock that ensures the interesting tuple(s) won't change.)
111 */
114 /*
115 * If the table is large relative to NBuffers, use a bulk-read access
116 * strategy and enable synchronized scanning (see syncscan.c). Although
117 * the thresholds for these features could be different, we make them the
118 * same so that there are only two behaviors to tune rather than four.
119 * (However, some callers need to be able to disable one or both of these
120 * behaviors, independently of the size of the table; also there is a GUC
121 * variable that can disable synchronized scanning.)
122 *
123 * During a rescan, don't make a new strategy object if we don't have to.
124 */
127 {
130 }
131 else
135 {
138 }
139 else
140 {
144 }
147 {
148 /*
149 * If rescan, keep the previous startblock setting so that rewinding a
150 * cursor doesn't generate surprising results. Reset the syncscan
151 * setting, though.
152 */
154 }
156 {
159 }
160 else
161 {
164 }
172 /* we don't have a marked position... */
175 /* page-at-a-time fields are always invalid when not rs_inited */
177 /*
178 * copy the scan key, if appropriate
179 */
183 /*
184 * Currently, we don't have a stats counter for bitmap heap scans (but the
185 * underlying bitmap index scans will be counted).
186 */
189 }
191 /*
192 * heapgetpage - subroutine for heapgettup()
193 *
194 * This routine reads and pins the specified page of the relation.
195 * In page-at-a-time mode it performs additional work, namely determining
196 * which tuples on the page are visible.
197 */
198 static void
200 {
201 Buffer buffer;
202 Snapshot snapshot;
203 Page dp;
206 OffsetNumber lineoff;
207 ItemId lpp;
212 /* release previous scan buffer, if any */
214 {
217 }
219 /* read page using selected strategy */
230 /*
231 * Prune and repair fragmentation for the whole page, if possible.
232 */
236 /*
237 * We must hold share lock on the buffer content while examining tuple
238 * visibility. Afterwards, however, the tuples we have found to be
239 * visible are guaranteed good as long as we hold the buffer pin.
240 */
247 /*
248 * If the all-visible flag indicates that all tuples on the page are
249 * visible to everyone, we can skip the per-tuple visibility tests.
250 */
256 {
258 {
263 else
264 {
265 HeapTupleData loctup;
272 }
275 }
276 }
282 }
284 /* ----------------
285 * heapgettup - fetch next heap tuple
286 *
287 * Initialize the scan if not already done; then advance to the next
288 * tuple as indicated by "dir"; return the next tuple in scan->rs_ctup,
289 * or set scan->rs_ctup.t_data = NULL if no more tuples.
290 *
291 * dir == NoMovementScanDirection means "re-fetch the tuple indicated
292 * by scan->rs_ctup".
293 *
294 * Note: the reason nkeys/key are passed separately, even though they are
295 * kept in the scan descriptor, is that the caller may not want us to check
296 * the scankeys.
297 *
298 * Note: when we fall off the end of the scan in either direction, we
299 * reset rs_inited. This means that a further request with the same
300 * scan direction will restart the scan, which is a bit odd, but a
301 * request with the opposite scan direction will start a fresh scan
302 * in the proper direction. The latter is required behavior for cursors,
303 * while the former case is generally undefined behavior in Postgres
304 * so we don't care too much.
305 * ----------------
306 */
307 static void
309 ScanDirection dir,
311 ScanKey key)
312 {
316 BlockNumber page;
318 Page dp;
320 OffsetNumber lineoff;
322 ItemId lpp;
324 /*
325 * calculate next starting lineoff, given scan direction
326 */
328 {
330 {
331 /*
332 * return null immediately if relation is empty
333 */
335 {
339 }
344 }
345 else
346 {
347 /* continue from previously returned page/tuple */
351 }
357 /* page and lineoff now reference the physically next tid */
360 }
362 {
364 {
365 /*
366 * return null immediately if relation is empty
367 */
369 {
373 }
375 /*
376 * Disable reporting to syncscan logic in a backwards scan; it's
377 * not very likely anyone else is doing the same thing at the same
378 * time, and much more likely that we'll just bollix things for
379 * forward scanners.
380 */
382 /* start from last page of the scan */
385 else
388 }
389 else
390 {
391 /* continue from previously returned page/tuple */
393 }
401 {
404 }
405 else
406 {
409 }
410 /* page and lineoff now reference the physically previous tid */
413 }
414 else
415 {
416 /*
417 * ``no movement'' scan direction: refetch prior tuple
418 */
420 {
424 }
430 /* Since the tuple was previously fetched, needn't lock page here */
440 }
442 /*
443 * advance the scan until we find a qualifying tuple or run out of stuff
444 * to scan
445 */
448 {
450 {
452 {
459 /*
460 * if current tuple qualifies, return it.
461 */
463 snapshot,
471 {
474 }
475 }
477 /*
478 * otherwise move to the next item on the page
479 */
482 {
485 }
486 else
487 {
490 }
491 }
493 /*
494 * if we get here, it means we've exhausted the items on this page and
495 * it's time to move to the next.
496 */
499 /*
500 * advance to next/prior page and detect end of scan
501 */
503 {
507 page--;
508 }
509 else
510 {
511 page++;
516 /*
517 * Report our new scan position for synchronization purposes. We
518 * don't do that when moving backwards, however. That would just
519 * mess up any other forward-moving scanners.
520 *
521 * Note: we do this before checking for end of scan so that the
522 * final state of the position hint is back at the start of the
523 * rel. That's not strictly necessary, but otherwise when you run
524 * the same query multiple times the starting position would shift
525 * a little bit backwards on every invocation, which is confusing.
526 * We don't guarantee any specific ordering in general, though.
527 */
530 }
532 /*
533 * return NULL if we've exhausted all the pages
534 */
536 {
544 }
554 {
557 }
558 else
559 {
562 }
563 }
564 }
566 /* ----------------
567 * heapgettup_pagemode - fetch next heap tuple in page-at-a-time mode
568 *
569 * Same API as heapgettup, but used in page-at-a-time mode
570 *
571 * The internal logic is much the same as heapgettup's too, but there are some
572 * differences: we do not take the buffer content lock (that only needs to
573 * happen inside heapgetpage), and we iterate through just the tuples listed
574 * in rs_vistuples[] rather than all tuples on the page. Notice that
575 * lineindex is 0-based, where the corresponding loop variable lineoff in
576 * heapgettup is 1-based.
577 * ----------------
578 */
579 static void
581 ScanDirection dir,
583 ScanKey key)
584 {
587 BlockNumber page;
589 Page dp;
592 OffsetNumber lineoff;
594 ItemId lpp;
596 /*
597 * calculate next starting lineindex, given scan direction
598 */
600 {
602 {
603 /*
604 * return null immediately if relation is empty
605 */
607 {
611 }
616 }
617 else
618 {
619 /* continue from previously returned page/tuple */
622 }
626 /* page and lineindex now reference the next visible tid */
629 }
631 {
633 {
634 /*
635 * return null immediately if relation is empty
636 */
638 {
642 }
644 /*
645 * Disable reporting to syncscan logic in a backwards scan; it's
646 * not very likely anyone else is doing the same thing at the same
647 * time, and much more likely that we'll just bollix things for
648 * forward scanners.
649 */
651 /* start from last page of the scan */
654 else
657 }
658 else
659 {
660 /* continue from previously returned page/tuple */
662 }
668 {
671 }
672 else
673 {
675 }
676 /* page and lineindex now reference the previous visible tid */
679 }
680 else
681 {
682 /*
683 * ``no movement'' scan direction: refetch prior tuple
684 */
686 {
690 }
696 /* Since the tuple was previously fetched, needn't lock page here */
705 /* check that rs_cindex is in sync */
710 }
712 /*
713 * advance the scan until we find a qualifying tuple or run out of stuff
714 * to scan
715 */
717 {
719 {
728 /*
729 * if current tuple qualifies, return it.
730 */
732 {
738 {
741 }
742 }
743 else
744 {
747 }
749 /*
750 * otherwise move to the next item on the page
751 */
755 else
757 }
759 /*
760 * if we get here, it means we've exhausted the items on this page and
761 * it's time to move to the next.
762 */
764 {
768 page--;
769 }
770 else
771 {
772 page++;
777 /*
778 * Report our new scan position for synchronization purposes. We
779 * don't do that when moving backwards, however. That would just
780 * mess up any other forward-moving scanners.
781 *
782 * Note: we do this before checking for end of scan so that the
783 * final state of the position hint is back at the start of the
784 * rel. That's not strictly necessary, but otherwise when you run
785 * the same query multiple times the starting position would shift
786 * a little bit backwards on every invocation, which is confusing.
787 * We don't guarantee any specific ordering in general, though.
788 */
791 }
793 /*
794 * return NULL if we've exhausted all the pages
795 */
797 {
805 }
814 else
816 }
817 }
820 #if defined(DISABLE_COMPLEX_MACRO)
821 /*
822 * This is formatted so oddly so that the correspondence to the macro
823 * definition in access/heapam.h is maintained.
824 */
825 Datum
828 {
831 (
834 (
836 (
840 )
841 :
843 )
844 :
845 (
847 (
850 )
851 :
852 (
854 )
855 )
856 )
857 :
858 (
860 )
861 );
862 }
866 /* ----------------------------------------------------------------
867 * heap access method interface
868 * ----------------------------------------------------------------
869 */
871 /* ----------------
872 * relation_open - open any relation by relation OID
873 *
874 * If lockmode is not "NoLock", the specified kind of lock is
875 * obtained on the relation. (Generally, NoLock should only be
876 * used if the caller knows it has some appropriate lock on the
877 * relation already.)
878 *
879 * An error is raised if the relation does not exist.
880 *
881 * NB: a "relation" is anything with a pg_class entry. The caller is
882 * expected to check whether the relkind is something it can handle.
883 * ----------------
884 */
885 Relation
887 {
888 Relation r;
892 /* Get the lock before trying to open the relcache entry */
896 /* The relcache does all the real work... */
902 /* Make note that we've accessed a temporary relation */
909 }
911 /* ----------------
912 * try_relation_open - open any relation by relation OID
913 *
914 * Same as relation_open, except return NULL instead of failing
915 * if the relation does not exist.
916 * ----------------
917 */
918 Relation
920 {
921 Relation r;
925 /* Get the lock first */
929 /*
930 * Now that we have the lock, probe to see if the relation really exists
931 * or not.
932 */
936 {
937 /* Release useless lock */
942 }
944 /* Should be safe to do a relcache load */
950 /* Make note that we've accessed a temporary relation */
957 }
959 /* ----------------
960 * relation_openrv - open any relation specified by a RangeVar
961 *
962 * Same as relation_open, but the relation is specified by a RangeVar.
963 * ----------------
964 */
965 Relation
967 {
968 Oid relOid;
970 /*
971 * Check for shared-cache-inval messages before trying to open the
972 * relation. This is needed to cover the case where the name identifies a
973 * rel that has been dropped and recreated since the start of our
974 * transaction: if we don't flush the old syscache entry then we'll latch
975 * onto that entry and suffer an error when we do RelationIdGetRelation.
976 * Note that relation_open does not need to do this, since a relation's
977 * OID never changes.
978 *
979 * We skip this if asked for NoLock, on the assumption that the caller has
980 * already ensured some appropriate lock is held.
981 */
985 /* Look up the appropriate relation using namespace search */
988 /* Let relation_open do the rest */
990 }
992 /* ----------------
993 * try_relation_openrv - open any relation specified by a RangeVar
994 *
995 * Same as relation_openrv, but return NULL instead of failing for
996 * relation-not-found. (Note that some other causes, such as
997 * permissions problems, will still result in an ereport.)
998 * ----------------
999 */
1000 Relation
1002 {
1003 Oid relOid;
1005 /*
1006 * Check for shared-cache-inval messages before trying to open the
1007 * relation. This is needed to cover the case where the name identifies a
1008 * rel that has been dropped and recreated since the start of our
1009 * transaction: if we don't flush the old syscache entry then we'll latch
1010 * onto that entry and suffer an error when we do RelationIdGetRelation.
1011 * Note that relation_open does not need to do this, since a relation's
1012 * OID never changes.
1013 *
1014 * We skip this if asked for NoLock, on the assumption that the caller has
1015 * already ensured some appropriate lock is held.
1016 */
1020 /* Look up the appropriate relation using namespace search */
1023 /* Return NULL on not-found */
1027 /* Let relation_open do the rest */
1029 }
1031 /* ----------------
1032 * relation_close - close any relation
1033 *
1034 * If lockmode is not "NoLock", we then release the specified lock.
1035 *
1036 * Note that it is often sensible to hold a lock beyond relation_close;
1037 * in that case, the lock is released automatically at xact end.
1038 * ----------------
1039 */
1040 void
1042 {
1047 /* The relcache does the real work... */
1052 }
1055 /* ----------------
1056 * heap_open - open a heap relation by relation OID
1057 *
1058 * This is essentially relation_open plus check that the relation
1059 * is not an index nor a composite type. (The caller should also
1060 * check that it's not a view before assuming it has storage.)
1061 * ----------------
1062 */
1063 Relation
1065 {
1066 Relation r;
1082 }
1084 /* ----------------
1085 * heap_openrv - open a heap relation specified
1086 * by a RangeVar node
1087 *
1088 * As above, but relation is specified by a RangeVar.
1089 * ----------------
1090 */
1091 Relation
1093 {
1094 Relation r;
1110 }
1112 /* ----------------
1113 * try_heap_openrv - open a heap relation specified
1114 * by a RangeVar node
1115 *
1116 * As above, but return NULL instead of failing for relation-not-found.
1117 * ----------------
1118 */
1119 Relation
1121 {
1122 Relation r;
1127 {
1138 }
1141 }
1144 /* ----------------
1145 * heap_beginscan - begin relation scan
1146 *
1147 * heap_beginscan_strat offers an extended API that lets the caller control
1148 * whether a nondefault buffer access strategy can be used, and whether
1149 * syncscan can be chosen (possibly resulting in the scan not starting from
1150 * block zero). Both of these default to TRUE with plain heap_beginscan.
1151 *
1152 * heap_beginscan_bm is an alternative entry point for setting up a
1153 * HeapScanDesc for a bitmap heap scan. Although that scan technology is
1154 * really quite unlike a standard seqscan, there is just enough commonality
1155 * to make it worth using the same data structure.
1156 * ----------------
1157 */
1158 HeapScanDesc
1161 {
1164 }
1166 HeapScanDesc
1170 {
1173 }
1175 HeapScanDesc
1178 {
1181 }
1183 static HeapScanDesc
1188 {
1189 HeapScanDesc scan;
1191 /*
1192 * increment relation ref count while scanning relation
1193 *
1194 * This is just to make really sure the relcache entry won't go away while
1195 * the scan has a pointer to it. Caller should be holding the rel open
1196 * anyway, so this is redundant in all normal scenarios...
1197 */
1200 /*
1201 * allocate and initialize scan descriptor
1202 */
1213 /*
1214 * we can use page-at-a-time mode if it's an MVCC-safe snapshot
1215 */
1218 /* we only need to set this up once */
1221 /*
1222 * we do this here instead of in initscan() because heap_rescan also calls
1223 * initscan() and we don't want to allocate memory again
1224 */
1227 else
1233 }
1235 /* ----------------
1236 * heap_rescan - restart a relation scan
1237 * ----------------
1238 */
1239 void
1241 ScanKey key)
1242 {
1243 /*
1244 * unpin scan buffers
1245 */
1249 /*
1250 * reinitialize scan descriptor
1251 */
1253 }
1255 /* ----------------
1256 * heap_endscan - end relation scan
1257 *
1258 * See how to integrate with index scans.
1259 * Check handling if reldesc caching.
1260 * ----------------
1261 */
1262 void
1264 {
1265 /* Note: no locking manipulations needed */
1267 /*
1268 * unpin scan buffers
1269 */
1273 /*
1274 * decrement relation reference count and free scan descriptor storage
1275 */
1285 }
1287 /* ----------------
1288 * heap_getnext - retrieve next tuple in scan
1289 *
1290 * Fix to work with index relations.
1291 * We don't return the buffer anymore, but you can get it from the
1292 * returned HeapTuple.
1293 * ----------------
1294 */
1296 #ifdef HEAPDEBUGALL
1297 #define HEAPDEBUG_1 \
1299 RelationGetRelationName(scan->rs_rd), scan->rs_nkeys, (int) direction)
1300 #define HEAPDEBUG_2 \
1302 #define HEAPDEBUG_3 \
1304 #else
1305 #define HEAPDEBUG_1
1306 #define HEAPDEBUG_2
1307 #define HEAPDEBUG_3
1311 HeapTuple
1313 {
1314 /* Note: no locking manipulations needed */
1321 else
1325 {
1328 }
1330 /*
1331 * if we get here it means we have a new current scan tuple, so point to
1332 * the proper return buffer and return the tuple.
1333 */
1339 }
1341 /*
1342 * heap_fetch - retrieve tuple with given tid
1343 *
1344 * On entry, tuple->t_self is the TID to fetch. We pin the buffer holding
1345 * the tuple, fill in the remaining fields of *tuple, and check the tuple
1346 * against the specified snapshot.
1347 *
1348 * If successful (tuple found and passes snapshot time qual), then *userbuf
1349 * is set to the buffer holding the tuple and TRUE is returned. The caller
1350 * must unpin the buffer when done with the tuple.
1351 *
1352 * If the tuple is not found (ie, item number references a deleted slot),
1353 * then tuple->t_data is set to NULL and FALSE is returned.
1354 *
1355 * If the tuple is found but fails the time qual check, then FALSE is returned
1356 * but tuple->t_data is left pointing to the tuple.
1357 *
1358 * keep_buf determines what is done with the buffer in the FALSE-result cases.
1359 * When the caller specifies keep_buf = true, we retain the pin on the buffer
1360 * and return it in *userbuf (so the caller must eventually unpin it); when
1361 * keep_buf = false, the pin is released and *userbuf is set to InvalidBuffer.
1362 *
1363 * stats_relation is the relation to charge the heap_fetch operation against
1364 * for statistical purposes. (This could be the heap rel itself, an
1365 * associated index, or NULL to not count the fetch at all.)
1366 *
1367 * heap_fetch does not follow HOT chains: only the exact TID requested will
1368 * be fetched.
1369 *
1370 * It is somewhat inconsistent that we ereport() on invalid block number but
1371 * return false on invalid item number. There are a couple of reasons though.
1372 * One is that the caller can relatively easily check the block number for
1373 * validity, but cannot check the item number without reading the page
1374 * himself. Another is that when we are following a t_ctid link, we can be
1375 * reasonably confident that the page number is valid (since VACUUM shouldn't
1376 * truncate off the destination page without having killed the referencing
1377 * tuple first), but the item number might well not be good.
1378 */
1379 bool
1381 Snapshot snapshot,
1382 HeapTuple tuple,
1385 Relation stats_relation)
1386 {
1388 ItemId lp;
1389 Buffer buffer;
1390 Page page;
1391 OffsetNumber offnum;
1394 /*
1395 * Fetch and pin the appropriate page of the relation.
1396 */
1399 /*
1400 * Need share lock on buffer to examine tuple commit status.
1401 */
1405 /*
1406 * We'd better check for out-of-range offnum in case of VACUUM since the
1407 * TID was obtained.
1408 */
1411 {
1415 else
1416 {
1419 }
1422 }
1424 /*
1425 * get the item line pointer corresponding to the requested tid
1426 */
1429 /*
1430 * Must check for deleted tuple.
1431 */
1433 {
1437 else
1438 {
1441 }
1444 }
1446 /*
1447 * fill in *tuple fields
1448 */
1453 /*
1454 * check time qualification of tuple, then release lock
1455 */
1461 {
1462 /*
1463 * All checks passed, so return the tuple as valid. Caller is now
1464 * responsible for releasing the buffer.
1465 */
1468 /* Count the successful fetch against appropriate rel, if any */
1473 }
1475 /* Tuple failed time qual, but maybe caller wants to see it anyway. */
1478 else
1479 {
1482 }
1485 }
1487 /*
1488 * heap_hot_search_buffer - search HOT chain for tuple satisfying snapshot
1489 *
1490 * On entry, *tid is the TID of a tuple (either a simple tuple, or the root
1491 * of a HOT chain), and buffer is the buffer holding this tuple. We search
1492 * for the first chain member satisfying the given snapshot. If one is
1493 * found, we update *tid to reference that tuple's offset number, and
1494 * return TRUE. If no match, return FALSE without modifying *tid.
1495 *
1496 * If all_dead is not NULL, we check non-visible tuples to see if they are
1497 * globally dead; *all_dead is set TRUE if all members of the HOT chain
1498 * are vacuumable, FALSE if not.
1499 *
1500 * Unlike heap_fetch, the caller must already have pin and (at least) share
1501 * lock on the buffer; it is still pinned/locked at exit. Also unlike
1502 * heap_fetch, we do not report any pgstats count; caller may do so if wanted.
1503 */
1504 bool
1507 {
1510 OffsetNumber offnum;
1522 /* Scan through possible multiple members of HOT-chain */
1524 {
1525 ItemId lp;
1526 HeapTupleData heapTuple;
1528 /* check for bogus TID */
1534 /* check for unused, dead, or redirected items */
1536 {
1537 /* We should only see a redirect at start of chain */
1539 {
1540 /* Follow the redirect */
1544 }
1545 /* else must be end of chain */
1547 }
1552 /*
1553 * Shouldn't see a HEAP_ONLY tuple at chain start.
1554 */
1558 /*
1559 * The xmin should match the previous xmax value, else chain is
1560 * broken.
1561 */
1567 /* If it's visible per the snapshot, we must return it */
1569 {
1574 }
1576 /*
1577 * If we can't see it, maybe no one else can either. At caller
1578 * request, check whether all chain members are dead to all
1579 * transactions.
1580 */
1586 /*
1587 * Check to see if HOT chain continues past this tuple; if so fetch
1588 * the next offnum and loop around.
1589 */
1591 {
1597 }
1598 else
1600 }
1603 }
1605 /*
1606 * heap_hot_search - search HOT chain for tuple satisfying snapshot
1607 *
1608 * This has the same API as heap_hot_search_buffer, except that the caller
1609 * does not provide the buffer containing the page, rather we access it
1610 * locally.
1611 */
1612 bool
1615 {
1617 Buffer buffer;
1625 }
1627 /*
1628 * heap_get_latest_tid - get the latest tid of a specified tuple
1629 *
1630 * Actually, this gets the latest version that is visible according to
1631 * the passed snapshot. You can pass SnapshotDirty to get the very latest,
1632 * possibly uncommitted version.
1633 *
1634 * *tid is both an input and an output parameter: it is updated to
1635 * show the latest version of the row. Note that it will not be changed
1636 * if no version of the row passes the snapshot test.
1637 */
1638 void
1640 Snapshot snapshot,
1641 ItemPointer tid)
1642 {
1643 BlockNumber blk;
1644 ItemPointerData ctid;
1645 TransactionId priorXmax;
1647 /* this is to avoid Assert failures on bad input */
1651 /*
1652 * Since this can be called with user-supplied TID, don't trust the input
1653 * too much. (RelationGetNumberOfBlocks is an expensive check, so we
1654 * don't check t_ctid links again this way. Note that it would not do to
1655 * call it just once and save the result, either.)
1656 */
1662 /*
1663 * Loop to chase down t_ctid links. At top of loop, ctid is the tuple we
1664 * need to examine, and *tid is the TID we will return if ctid turns out
1665 * to be bogus.
1666 *
1667 * Note that we will loop until we reach the end of the t_ctid chain.
1668 * Depending on the snapshot passed, there might be at most one visible
1669 * version of the row, but we don't try to optimize for that.
1670 */
1674 {
1675 Buffer buffer;
1676 Page page;
1677 OffsetNumber offnum;
1678 ItemId lp;
1679 HeapTupleData tp;
1682 /*
1683 * Read, pin, and lock the page.
1684 */
1689 /*
1690 * Check for bogus item number. This is not treated as an error
1691 * condition because it can happen while following a t_ctid link. We
1692 * just assume that the prior tid is OK and return it unchanged.
1693 */
1696 {
1699 }
1702 {
1705 }
1707 /* OK to access the tuple */
1712 /*
1713 * After following a t_ctid link, we might arrive at an unrelated
1714 * tuple. Check for XMIN match.
1715 */
1718 {
1721 }
1723 /*
1724 * Check time qualification of tuple; if visible, set it as the new
1725 * result candidate.
1726 */
1731 /*
1732 * If there's a valid t_ctid link, follow it, else we're done.
1733 */
1736 {
1739 }
1745 }
1748 /*
1749 * UpdateXmaxHintBits - update tuple hint bits after xmax transaction ends
1750 *
1751 * This is called after we have waited for the XMAX transaction to terminate.
1752 * If the transaction aborted, we guarantee the XMAX_INVALID hint bit will
1753 * be set on exit. If the transaction committed, we set the XMAX_COMMITTED
1754 * hint bit if possible --- but beware that that may not yet be possible,
1755 * if the transaction committed asynchronously. Hence callers should look
1756 * only at XMAX_INVALID.
1757 */
1758 static void
1760 {
1764 {
1767 xid);
1768 else
1770 InvalidTransactionId);
1771 }
1772 }
1775 /*
1776 * GetBulkInsertState - prepare status object for a bulk insert
1777 */
1778 BulkInsertState
1780 {
1781 BulkInsertState bistate;
1787 }
1789 /*
1790 * FreeBulkInsertState - clean up after finishing a bulk insert
1791 */
1792 void
1794 {
1799 }
1802 /*
1803 * heap_insert - insert tuple into a heap
1804 *
1805 * The new tuple is stamped with current transaction ID and the specified
1806 * command ID.
1807 *
1808 * If the HEAP_INSERT_SKIP_WAL option is specified, the new tuple is not
1809 * logged in WAL, even for a non-temp relation. Safe usage of this behavior
1810 * requires that we arrange that all new tuples go into new pages not
1811 * containing any tuples from other transactions, and that the relation gets
1812 * fsync'd before commit. (See also heap_sync() comments)
1813 *
1814 * The HEAP_INSERT_SKIP_FSM option is passed directly to
1815 * RelationGetBufferForTuple, which see for more info.
1816 *
1817 * Note that these options will be applied when inserting into the heap's
1818 * TOAST table, too, if the tuple requires any out-of-line data.
1819 *
1820 * The BulkInsertState object (if any; bistate can be NULL for default
1821 * behavior) is also just passed through to RelationGetBufferForTuple.
1822 *
1823 * The return value is the OID assigned to the tuple (either here or by the
1824 * caller), or InvalidOid if no OID. The header fields of *tup are updated
1825 * to match the stored tuple; in particular tup->t_self receives the actual
1826 * TID where the tuple was stored. But note that any toasting of fields
1827 * within the tuple data is NOT reflected into *tup.
1828 */
1829 Oid
1832 {
1834 HeapTuple heaptup;
1835 Buffer buffer;
1839 {
1840 #ifdef NOT_USED
1841 /* this is redundant with an Assert in HeapTupleSetOid */
1843 #endif
1845 /*
1846 * If the object id of this tuple has already been assigned, trust the
1847 * caller. There are a couple of ways this can happen. At initial db
1848 * creation, the backend program sets oids for tuples. When we define
1849 * an index, we set the oid. Finally, in the future, we may allow
1850 * users to set their own object ids in order to support a persistent
1851 * object store (objects need to contain pointers to one another).
1852 */
1855 }
1856 else
1857 {
1858 /* check there is not space for an OID */
1860 }
1870 /*
1871 * If the new tuple is too big for storage or contains already toasted
1872 * out-of-line attributes from some other relation, invoke the toaster.
1873 *
1874 * Note: below this point, heaptup is the data we actually intend to store
1875 * into the relation; tup is the caller's original untoasted data.
1876 */
1878 {
1879 /* toast table entries should never be recursively toasted */
1882 }
1885 else
1888 /* Find buffer to insert this tuple into */
1892 /* NO EREPORT(ERROR) from here till changes are logged */
1898 {
1901 }
1903 /*
1904 * XXX Should we set PageSetPrunable on this page ?
1905 *
1906 * The inserting transaction may eventually abort thus making this tuple
1907 * DEAD and hence available for pruning. Though we don't want to optimize
1908 * for aborts, if no other tuple in this page is UPDATEd/DELETEd, the
1909 * aborted tuple will never be pruned until next vacuum is triggered.
1910 *
1911 * If you do add PageSetPrunable here, add it in heap_xlog_insert too.
1912 */
1916 /* XLOG stuff */
1918 {
1919 xl_heap_insert xlrec;
1920 xl_heap_header xlhdr;
1921 XLogRecPtr recptr;
1938 /*
1939 * note we mark rdata[1] as belonging to buffer; if XLogInsert decides
1940 * to write the whole page to the xlog, we don't need to store
1941 * xl_heap_header in the xlog.
1942 */
1949 /* PG73FORMAT: write bitmap [+ padding] [+ oid] + data */
1956 /*
1957 * If this is the single and first tuple on page, we can reinit the
1958 * page instead of restoring the whole thing. Set flag, and hide
1959 * buffer references from XLogInsert.
1960 */
1963 {
1966 }
1972 }
1978 /* Clear the bit in the visibility map if necessary */
1983 /*
1984 * If tuple is cachable, mark it for invalidation from the caches in case
1985 * we abort. Note it is OK to do this after releasing the buffer, because
1986 * the heaptup data structure is all in local memory, not in the shared
1987 * buffer.
1988 */
1993 /*
1994 * If heaptup is a private copy, release it. Don't forget to copy t_self
1995 * back to the caller's image, too.
1996 */
1998 {
2001 }
2004 }
2006 /*
2007 * simple_heap_insert - insert a tuple
2008 *
2009 * Currently, this routine differs from heap_insert only in supplying
2010 * a default command ID and not allowing access to the speedup options.
2011 *
2012 * This should be used rather than using heap_insert directly in most places
2013 * where we are modifying system catalogs.
2014 */
2015 Oid
2017 {
2019 }
2021 /*
2022 * heap_delete - delete a tuple
2023 *
2024 * NB: do not call this directly unless you are prepared to deal with
2025 * concurrent-update conditions. Use simple_heap_delete instead.
2026 *
2027 * relation - table to be modified (caller must hold suitable lock)
2028 * tid - TID of tuple to be deleted
2029 * ctid - output parameter, used only for failure case (see below)
2030 * update_xmax - output parameter, used only for failure case (see below)
2031 * cid - delete command ID (used for visibility test, and stored into
2032 * cmax if successful)
2033 * crosscheck - if not InvalidSnapshot, also check tuple against this
2034 * wait - true if should wait for any conflicting update to commit/abort
2035 *
2036 * Normal, successful return value is HeapTupleMayBeUpdated, which
2037 * actually means we did delete it. Failure return codes are
2038 * HeapTupleSelfUpdated, HeapTupleUpdated, or HeapTupleBeingUpdated
2039 * (the last only possible if wait == false).
2040 *
2041 * In the failure cases, the routine returns the tuple's t_ctid and t_xmax.
2042 * If t_ctid is the same as tid, the tuple was deleted; if different, the
2043 * tuple was updated, and t_ctid is the location of the replacement tuple.
2044 * (t_xmax is needed to verify that the replacement tuple matches.)
2045 */
2046 HTSU_Result
2050 {
2051 HTSU_Result result;
2053 ItemId lp;
2054 HeapTupleData tp;
2055 Page page;
2056 Buffer buffer;
2074 l1:
2078 {
2081 }
2083 {
2084 TransactionId xwait;
2085 uint16 infomask;
2087 /* must copy state data before unlocking buffer */
2093 /*
2094 * Acquire tuple lock to establish our priority for the tuple (see
2095 * heap_lock_tuple). LockTuple will release us when we are
2096 * next-in-line for the tuple.
2097 *
2098 * If we are forced to "start over" below, we keep the tuple lock;
2099 * this arranges that we stay at the head of the line while rechecking
2100 * tuple state.
2101 */
2103 {
2106 }
2108 /*
2109 * Sleep until concurrent transaction ends. Note that we don't care
2110 * if the locker has an exclusive or shared lock, because we need
2111 * exclusive.
2112 */
2115 {
2116 /* wait for multixact */
2120 /*
2121 * If xwait had just locked the tuple then some other xact could
2122 * update this tuple before we get to this point. Check for xmax
2123 * change, and start over if so.
2124 */
2127 xwait))
2130 /*
2131 * You might think the multixact is necessarily done here, but not
2132 * so: it could have surviving members, namely our own xact or
2133 * other subxacts of this backend. It is legal for us to delete
2134 * the tuple in either case, however (the latter case is
2135 * essentially a situation of upgrading our former shared lock to
2136 * exclusive). We don't bother changing the on-disk hint bits
2137 * since we are about to overwrite the xmax altogether.
2138 */
2139 }
2140 else
2141 {
2142 /* wait for regular transaction to end */
2146 /*
2147 * xwait is done, but if xwait had just locked the tuple then some
2148 * other xact could update this tuple before we get to this point.
2149 * Check for xmax change, and start over if so.
2150 */
2153 xwait))
2156 /* Otherwise check if it committed or aborted */
2158 }
2160 /*
2161 * We may overwrite if previous xmax aborted, or if it committed but
2162 * only locked the tuple without updating it.
2163 */
2165 HEAP_IS_LOCKED))
2167 else
2169 }
2172 {
2173 /* Perform additional check for serializable RI updates */
2176 }
2179 {
2190 }
2192 /* replace cid with a combo cid if necessary */
2197 /*
2198 * If this transaction commits, the tuple will become DEAD sooner or
2199 * later. Set flag that this page is a candidate for pruning once our xid
2200 * falls below the OldestXmin horizon. If the transaction finally aborts,
2201 * the subsequent page pruning will be a no-op and the hint will be
2202 * cleared.
2203 */
2207 {
2210 }
2212 /* store transaction information of xact deleting the tuple */
2214 HEAP_XMAX_INVALID |
2215 HEAP_XMAX_IS_MULTI |
2216 HEAP_IS_LOCKED |
2217 HEAP_MOVED);
2221 /* Make sure there is no forward chain link in t_ctid */
2226 /* XLOG stuff */
2228 {
2229 xl_heap_delete xlrec;
2230 XLogRecPtr recptr;
2251 }
2257 /*
2258 * If the tuple has toasted out-of-line attributes, we need to delete
2259 * those items too. We have to do this before releasing the buffer
2260 * because we need to look at the contents of the tuple, but it's OK to
2261 * release the content lock on the buffer first.
2262 */
2264 {
2265 /* toast table entries should never be recursively toasted */
2267 }
2271 /*
2272 * Mark tuple for invalidation from system caches at next command
2273 * boundary. We have to do this before releasing the buffer because we
2274 * need to look at the contents of the tuple.
2275 */
2278 /* Clear the bit in the visibility map if necessary */
2282 /* Now we can release the buffer */
2285 /*
2286 * Release the lmgr tuple lock, if we had it.
2287 */
2294 }
2296 /*
2297 * simple_heap_delete - delete a tuple
2298 *
2299 * This routine may be used to delete a tuple when concurrent updates of
2300 * the target tuple are not expected (for example, because we have a lock
2301 * on the relation associated with the tuple). Any failure is reported
2302 * via ereport().
2303 */
2304 void
2306 {
2307 HTSU_Result result;
2308 ItemPointerData update_ctid;
2309 TransactionId update_xmax;
2316 {
2318 /* Tuple was already updated in current command? */
2323 /* done successfully */
2333 }
2334 }
2336 /*
2337 * heap_update - replace a tuple
2338 *
2339 * NB: do not call this directly unless you are prepared to deal with
2340 * concurrent-update conditions. Use simple_heap_update instead.
2341 *
2342 * relation - table to be modified (caller must hold suitable lock)
2343 * otid - TID of old tuple to be replaced
2344 * newtup - newly constructed tuple data to store
2345 * ctid - output parameter, used only for failure case (see below)
2346 * update_xmax - output parameter, used only for failure case (see below)
2347 * cid - update command ID (used for visibility test, and stored into
2348 * cmax/cmin if successful)
2349 * crosscheck - if not InvalidSnapshot, also check old tuple against this
2350 * wait - true if should wait for any conflicting update to commit/abort
2351 *
2352 * Normal, successful return value is HeapTupleMayBeUpdated, which
2353 * actually means we *did* update it. Failure return codes are
2354 * HeapTupleSelfUpdated, HeapTupleUpdated, or HeapTupleBeingUpdated
2355 * (the last only possible if wait == false).
2356 *
2357 * On success, the header fields of *newtup are updated to match the new
2358 * stored tuple; in particular, newtup->t_self is set to the TID where the
2359 * new tuple was inserted, and its HEAP_ONLY_TUPLE flag is set iff a HOT
2360 * update was done. However, any TOAST changes in the new tuple's
2361 * data are not reflected into *newtup.
2362 *
2363 * In the failure cases, the routine returns the tuple's t_ctid and t_xmax.
2364 * If t_ctid is the same as otid, the tuple was deleted; if different, the
2365 * tuple was updated, and t_ctid is the location of the replacement tuple.
2366 * (t_xmax is needed to verify that the replacement tuple matches.)
2367 */
2368 HTSU_Result
2372 {
2373 HTSU_Result result;
2376 ItemId lp;
2377 HeapTupleData oldtup;
2378 HeapTuple heaptup;
2379 Page page;
2380 Buffer buffer,
2381 newbuf;
2383 already_marked;
2384 Size newtupsize,
2385 pagefree;
2394 /*
2395 * Fetch the list of attributes to be checked for HOT update. This is
2396 * wasted effort if we fail to update or have to put the new tuple on a
2397 * different page. But we must compute the list before obtaining buffer
2398 * lock --- in the worst case, if we are doing an update on one of the
2399 * relevant system catalogs, we could deadlock if we try to fetch the list
2400 * later. In any case, the relcache caches the data so this is usually
2401 * pretty cheap.
2402 *
2403 * Note that we get a copy here, so we need not worry about relcache flush
2404 * happening midway through.
2405 */
2419 /*
2420 * Note: beyond this point, use oldtup not otid to refer to old tuple.
2421 * otid may very well point at newtup->t_self, which we will overwrite
2422 * with the new tuple's location, so there's great risk of confusion if we
2423 * use otid anymore.
2424 */
2426 l2:
2430 {
2433 }
2435 {
2436 TransactionId xwait;
2437 uint16 infomask;
2439 /* must copy state data before unlocking buffer */
2445 /*
2446 * Acquire tuple lock to establish our priority for the tuple (see
2447 * heap_lock_tuple). LockTuple will release us when we are
2448 * next-in-line for the tuple.
2449 *
2450 * If we are forced to "start over" below, we keep the tuple lock;
2451 * this arranges that we stay at the head of the line while rechecking
2452 * tuple state.
2453 */
2455 {
2458 }
2460 /*
2461 * Sleep until concurrent transaction ends. Note that we don't care
2462 * if the locker has an exclusive or shared lock, because we need
2463 * exclusive.
2464 */
2467 {
2468 /* wait for multixact */
2472 /*
2473 * If xwait had just locked the tuple then some other xact could
2474 * update this tuple before we get to this point. Check for xmax
2475 * change, and start over if so.
2476 */
2479 xwait))
2482 /*
2483 * You might think the multixact is necessarily done here, but not
2484 * so: it could have surviving members, namely our own xact or
2485 * other subxacts of this backend. It is legal for us to update
2486 * the tuple in either case, however (the latter case is
2487 * essentially a situation of upgrading our former shared lock to
2488 * exclusive). We don't bother changing the on-disk hint bits
2489 * since we are about to overwrite the xmax altogether.
2490 */
2491 }
2492 else
2493 {
2494 /* wait for regular transaction to end */
2498 /*
2499 * xwait is done, but if xwait had just locked the tuple then some
2500 * other xact could update this tuple before we get to this point.
2501 * Check for xmax change, and start over if so.
2502 */
2505 xwait))
2508 /* Otherwise check if it committed or aborted */
2510 }
2512 /*
2513 * We may overwrite if previous xmax aborted, or if it committed but
2514 * only locked the tuple without updating it.
2515 */
2517 HEAP_IS_LOCKED))
2519 else
2521 }
2524 {
2525 /* Perform additional check for serializable RI updates */
2528 }
2531 {
2543 }
2545 /* Fill in OID and transaction status data for newtup */
2547 {
2548 #ifdef NOT_USED
2549 /* this is redundant with an Assert in HeapTupleSetOid */
2551 #endif
2553 }
2554 else
2555 {
2556 /* check there is not space for an OID */
2558 }
2568 /*
2569 * Replace cid with a combo cid if necessary. Note that we already put
2570 * the plain cid into the new tuple.
2571 */
2574 /*
2575 * If the toaster needs to be activated, OR if the new tuple will not fit
2576 * on the same page as the old, then we need to release the content lock
2577 * (but not the pin!) on the old tuple's buffer while we are off doing
2578 * TOAST and/or table-file-extension work. We must mark the old tuple to
2579 * show that it's already being updated, else other processes may try to
2580 * update it themselves.
2581 *
2582 * We need to invoke the toaster if there are already any out-of-line
2583 * toasted values present, or if the new tuple is over-threshold.
2584 */
2586 {
2587 /* toast table entries should never be recursively toasted */
2591 }
2592 else
2602 {
2603 /* Clear obsolete visibility flags ... */
2605 HEAP_XMAX_INVALID |
2606 HEAP_XMAX_IS_MULTI |
2607 HEAP_IS_LOCKED |
2608 HEAP_MOVED);
2610 /* ... and store info about transaction updating this tuple */
2613 /* temporarily make it look not-updated */
2618 /*
2619 * Let the toaster do its thing, if needed.
2620 *
2621 * Note: below this point, heaptup is the data we actually intend to
2622 * store into the relation; newtup is the caller's original untoasted
2623 * data.
2624 */
2626 {
2627 /* Note we always use WAL and FSM during updates */
2630 }
2631 else
2634 /*
2635 * Now, do we need a new page for the tuple, or not? This is a bit
2636 * tricky since someone else could have added tuples to the page while
2637 * we weren't looking. We have to recheck the available space after
2638 * reacquiring the buffer lock. But don't bother to do that if the
2639 * former amount of free space is still not enough; it's unlikely
2640 * there's more free now than before.
2641 *
2642 * What's more, if we need to get a new page, we will need to acquire
2643 * buffer locks on both old and new pages. To avoid deadlock against
2644 * some other backend trying to get the same two locks in the other
2645 * order, we must be consistent about the order we get the locks in.
2646 * We use the rule "lock the lower-numbered page of the relation
2647 * first". To implement this, we must do RelationGetBufferForTuple
2648 * while not holding the lock on the old page, and we must rely on it
2649 * to get the locks on both pages in the correct order.
2650 */
2652 {
2653 /* Assume there's no chance to put heaptup on same page. */
2656 }
2657 else
2658 {
2659 /* Re-acquire the lock on the old tuple's page. */
2661 /* Re-check using the up-to-date free space */
2664 {
2665 /*
2666 * Rats, it doesn't fit anymore. We must now unlock and
2667 * relock to avoid deadlock. Fortunately, this path should
2668 * seldom be taken.
2669 */
2673 }
2674 else
2675 {
2676 /* OK, it fits here, so we're done. */
2678 }
2679 }
2680 }
2681 else
2682 {
2683 /* No TOAST work needed, and it'll fit on same page */
2687 }
2689 /*
2690 * At this point newbuf and buffer are both pinned and locked, and newbuf
2691 * has enough space for the new tuple. If they are the same buffer, only
2692 * one pin is held.
2693 */
2696 {
2697 /*
2698 * Since the new tuple is going into the same page, we might be able
2699 * to do a HOT update. Check if any of the index columns have been
2700 * changed. If not, then HOT update is possible.
2701 */
2704 }
2705 else
2706 {
2707 /* Set a hint that the old page could use prune/defrag */
2709 }
2711 /* NO EREPORT(ERROR) from here till changes are logged */
2714 /*
2715 * If this transaction commits, the old tuple will become DEAD sooner or
2716 * later. Set flag that this page is a candidate for pruning once our xid
2717 * falls below the OldestXmin horizon. If the transaction finally aborts,
2718 * the subsequent page pruning will be a no-op and the hint will be
2719 * cleared.
2720 *
2721 * XXX Should we set hint on newbuf as well? If the transaction aborts,
2722 * there would be a prunable tuple in the newbuf; but for now we choose
2723 * not to optimize for aborts. Note that heap_xlog_update must be kept in
2724 * sync if this decision changes.
2725 */
2729 {
2730 /* Mark the old tuple as HOT-updated */
2732 /* And mark the new tuple as heap-only */
2734 /* Mark the caller's copy too, in case different from heaptup */
2736 }
2737 else
2738 {
2739 /* Make sure tuples are correctly marked as not-HOT */
2743 }
2748 {
2749 /* Clear obsolete visibility flags ... */
2751 HEAP_XMAX_INVALID |
2752 HEAP_XMAX_IS_MULTI |
2753 HEAP_IS_LOCKED |
2754 HEAP_MOVED);
2755 /* ... and store info about transaction updating this tuple */
2758 }
2760 /* record address of new tuple in t_ctid of old one */
2767 /*
2768 * Note: we mustn't clear PD_ALL_VISIBLE flags before writing the WAL
2769 * record, because log_heap_update looks at those flags to set the
2770 * corresponding flags in the WAL record.
2771 */
2773 /* XLOG stuff */
2775 {
2780 {
2783 }
2786 }
2788 /* Clear PD_ALL_VISIBLE flags */
2790 {
2793 }
2795 {
2798 }
2806 /*
2807 * Mark old tuple for invalidation from system caches at next command
2808 * boundary. We have to do this before releasing the buffer because we
2809 * need to look at the contents of the tuple.
2810 */
2813 /* Clear bits in visibility map */
2819 /* Now we can release the buffer(s) */
2824 /*
2825 * If new tuple is cachable, mark it for invalidation from the caches in
2826 * case we abort. Note it is OK to do this after releasing the buffer,
2827 * because the heaptup data structure is all in local memory, not in the
2828 * shared buffer.
2829 */
2832 /*
2833 * Release the lmgr tuple lock, if we had it.
2834 */
2840 /*
2841 * If heaptup is a private copy, release it. Don't forget to copy t_self
2842 * back to the caller's image, too.
2843 */
2845 {
2848 }
2853 }
2855 /*
2856 * Check if the specified attribute's value is same in both given tuples.
2857 * Subroutine for HeapSatisfiesHOTUpdate.
2858 */
2859 static bool
2862 {
2863 Datum value1,
2864 value2;
2866 isnull2;
2867 Form_pg_attribute att;
2869 /*
2870 * If it's a whole-tuple reference, say "not equal". It's not really
2871 * worth supporting this case, since it could only succeed after a no-op
2872 * update, which is hardly a case worth optimizing for.
2873 */
2877 /*
2878 * Likewise, automatically say "not equal" for any system attribute other
2879 * than OID and tableOID; we cannot expect these to be consistent in a HOT
2880 * chain, or even to be set correctly yet in the new tuple.
2881 */
2883 {
2887 }
2889 /*
2890 * Extract the corresponding values. XXX this is pretty inefficient if
2891 * there are many indexed columns. Should HeapSatisfiesHOTUpdate do a
2892 * single heap_deform_tuple call on each tuple, instead? But that doesn't
2893 * work for system columns ...
2894 */
2898 /*
2899 * If one value is NULL and other is not, then they are certainly not
2900 * equal
2901 */
2905 /*
2906 * If both are NULL, they can be considered equal.
2907 */
2911 /*
2912 * We do simple binary comparison of the two datums. This may be overly
2913 * strict because there can be multiple binary representations for the
2914 * same logical value. But we should be OK as long as there are no false
2915 * positives. Using a type-specific equality operator is messy because
2916 * there could be multiple notions of equality in different operator
2917 * classes; furthermore, we cannot safely invoke user-defined functions
2918 * while holding exclusive buffer lock.
2919 */
2921 {
2922 /* The only allowed system columns are OIDs, so do this */
2924 }
2925 else
2926 {
2930 }
2931 }
2933 /*
2934 * Check if the old and new tuples represent a HOT-safe update. To be able
2935 * to do a HOT update, we must not have changed any columns used in index
2936 * definitions.
2937 *
2938 * The set of attributes to be checked is passed in (we dare not try to
2939 * compute it while holding exclusive buffer lock...) NOTE that hot_attrs
2940 * is destructively modified! That is OK since this is invoked at most once
2941 * by heap_update().
2942 *
2943 * Returns true if safe to do HOT update.
2944 */
2945 static bool
2948 {
2952 {
2953 /* Adjust for system attributes */
2956 /* If the attribute value has changed, we can't do HOT update */
2960 }
2963 }
2965 /*
2966 * simple_heap_update - replace a tuple
2967 *
2968 * This routine may be used to update a tuple when concurrent updates of
2969 * the target tuple are not expected (for example, because we have a lock
2970 * on the relation associated with the tuple). Any failure is reported
2971 * via ereport().
2972 */
2973 void
2975 {
2976 HTSU_Result result;
2977 ItemPointerData update_ctid;
2978 TransactionId update_xmax;
2985 {
2987 /* Tuple was already updated in current command? */
2992 /* done successfully */
3002 }
3003 }
3005 /*
3006 * heap_lock_tuple - lock a tuple in shared or exclusive mode
3007 *
3008 * Note that this acquires a buffer pin, which the caller must release.
3009 *
3010 * Input parameters:
3011 * relation: relation containing tuple (caller must hold suitable lock)
3012 * tuple->t_self: TID of tuple to lock (rest of struct need not be valid)
3013 * cid: current command ID (used for visibility test, and stored into
3014 * tuple's cmax if lock is successful)
3015 * mode: indicates if shared or exclusive tuple lock is desired
3016 * nowait: if true, ereport rather than blocking if lock not available
3017 *
3018 * Output parameters:
3019 * *tuple: all fields filled in
3020 * *buffer: set to buffer holding tuple (pinned but not locked at exit)
3021 * *ctid: set to tuple's t_ctid, but only in failure cases
3022 * *update_xmax: set to tuple's xmax, but only in failure cases
3023 *
3024 * Function result may be:
3025 * HeapTupleMayBeUpdated: lock was successfully acquired
3026 * HeapTupleSelfUpdated: lock failed because tuple updated by self
3027 * HeapTupleUpdated: lock failed because tuple updated by other xact
3028 *
3029 * In the failure cases, the routine returns the tuple's t_ctid and t_xmax.
3030 * If t_ctid is the same as t_self, the tuple was deleted; if different, the
3031 * tuple was updated, and t_ctid is the location of the replacement tuple.
3032 * (t_xmax is needed to verify that the replacement tuple matches.)
3033 *
3034 *
3035 * NOTES: because the shared-memory lock table is of finite size, but users
3036 * could reasonably want to lock large numbers of tuples, we do not rely on
3037 * the standard lock manager to store tuple-level locks over the long term.
3038 * Instead, a tuple is marked as locked by setting the current transaction's
3039 * XID as its XMAX, and setting additional infomask bits to distinguish this
3040 * usage from the more normal case of having deleted the tuple. When
3041 * multiple transactions concurrently share-lock a tuple, the first locker's
3042 * XID is replaced in XMAX with a MultiTransactionId representing the set of
3043 * XIDs currently holding share-locks.
3044 *
3045 * When it is necessary to wait for a tuple-level lock to be released, the
3046 * basic delay is provided by XactLockTableWait or MultiXactIdWait on the
3047 * contents of the tuple's XMAX. However, that mechanism will release all
3048 * waiters concurrently, so there would be a race condition as to which
3049 * waiter gets the tuple, potentially leading to indefinite starvation of
3050 * some waiters. The possibility of share-locking makes the problem much
3051 * worse --- a steady stream of share-lockers can easily block an exclusive
3052 * locker forever. To provide more reliable semantics about who gets a
3053 * tuple-level lock first, we use the standard lock manager. The protocol
3054 * for waiting for a tuple-level lock is really
3055 * LockTuple()
3056 * XactLockTableWait()
3057 * mark tuple as locked by me
3058 * UnlockTuple()
3059 * When there are multiple waiters, arbitration of who is to get the lock next
3060 * is provided by LockTuple(). However, at most one tuple-level lock will
3061 * be held or awaited per backend at any time, so we don't risk overflow
3062 * of the lock table. Note that incoming share-lockers are required to
3063 * do LockTuple as well, if there is any conflict, to ensure that they don't
3064 * starve out waiting exclusive-lockers. However, if there is not any active
3065 * conflict for a tuple, we don't incur any extra overhead.
3066 */
3067 HTSU_Result
3071 {
3072 HTSU_Result result;
3074 ItemId lp;
3075 Page page;
3076 TransactionId xid;
3077 TransactionId xmax;
3078 uint16 old_infomask;
3079 uint16 new_infomask;
3080 LOCKMODE tuple_lock_type;
3096 l3:
3100 {
3103 }
3105 {
3106 TransactionId xwait;
3107 uint16 infomask;
3109 /* must copy state data before unlocking buffer */
3115 /*
3116 * If we wish to acquire share lock, and the tuple is already
3117 * share-locked by a multixact that includes any subtransaction of the
3118 * current top transaction, then we effectively hold the desired lock
3119 * already. We *must* succeed without trying to take the tuple lock,
3120 * else we will deadlock against anyone waiting to acquire exclusive
3121 * lock. We don't need to make any state changes in this case.
3122 */
3126 {
3128 /* Probably can't hold tuple lock here, but may as well check */
3132 }
3134 /*
3135 * Acquire tuple lock to establish our priority for the tuple.
3136 * LockTuple will release us when we are next-in-line for the tuple.
3137 * We must do this even if we are share-locking.
3138 *
3139 * If we are forced to "start over" below, we keep the tuple lock;
3140 * this arranges that we stay at the head of the line while rechecking
3141 * tuple state.
3142 */
3144 {
3146 {
3152 }
3153 else
3156 }
3159 {
3160 /*
3161 * Acquiring sharelock when there's at least one sharelocker
3162 * already. We need not wait for him/them to complete.
3163 */
3166 /*
3167 * Make sure it's still a shared lock, else start over. (It's OK
3168 * if the ownership of the shared lock has changed, though.)
3169 */
3172 }
3174 {
3175 /* wait for multixact to end */
3177 {
3183 }
3184 else
3189 /*
3190 * If xwait had just locked the tuple then some other xact could
3191 * update this tuple before we get to this point. Check for xmax
3192 * change, and start over if so.
3193 */
3196 xwait))
3199 /*
3200 * You might think the multixact is necessarily done here, but not
3201 * so: it could have surviving members, namely our own xact or
3202 * other subxacts of this backend. It is legal for us to lock the
3203 * tuple in either case, however. We don't bother changing the
3204 * on-disk hint bits since we are about to overwrite the xmax
3205 * altogether.
3206 */
3207 }
3208 else
3209 {
3210 /* wait for regular transaction to end */
3212 {
3218 }
3219 else
3224 /*
3225 * xwait is done, but if xwait had just locked the tuple then some
3226 * other xact could update this tuple before we get to this point.
3227 * Check for xmax change, and start over if so.
3228 */
3231 xwait))
3234 /* Otherwise check if it committed or aborted */
3236 }
3238 /*
3239 * We may lock if previous xmax aborted, or if it committed but only
3240 * locked the tuple without updating it. The case where we didn't
3241 * wait because we are joining an existing shared lock is correctly
3242 * handled, too.
3243 */
3245 HEAP_IS_LOCKED))
3247 else
3249 }
3252 {
3261 }
3263 /*
3264 * We might already hold the desired lock (or stronger), possibly under a
3265 * different subtransaction of the current top transaction. If so, there
3266 * is no need to change state or issue a WAL record. We already handled
3267 * the case where this is true for xmax being a MultiXactId, so now check
3268 * for cases where it is a plain TransactionId.
3269 *
3270 * Note in particular that this covers the case where we already hold
3271 * exclusive lock on the tuple and the caller only wants shared lock. It
3272 * would certainly not do to give up the exclusive lock.
3273 */
3278 HEAP_XMAX_COMMITTED |
3279 HEAP_XMAX_IS_MULTI)) &&
3284 {
3286 /* Probably can't hold tuple lock here, but may as well check */
3290 }
3292 /*
3293 * Compute the new xmax and infomask to store into the tuple. Note we do
3294 * not modify the tuple just yet, because that would leave it in the wrong
3295 * state if multixact.c elogs.
3296 */
3300 HEAP_XMAX_INVALID |
3301 HEAP_XMAX_IS_MULTI |
3302 HEAP_IS_LOCKED |
3303 HEAP_MOVED);
3306 {
3307 /*
3308 * If this is the first acquisition of a shared lock in the current
3309 * transaction, set my per-backend OldestMemberMXactId setting. We can
3310 * be certain that the transaction will never become a member of any
3311 * older MultiXactIds than that. (We have to do this even if we end
3312 * up just using our own TransactionId below, since some other backend
3313 * could incorporate our XID into a MultiXact immediately afterwards.)
3314 */
3319 /*
3320 * Check to see if we need a MultiXactId because there are multiple
3321 * lockers.
3322 *
3323 * HeapTupleSatisfiesUpdate will have set the HEAP_XMAX_INVALID bit if
3324 * the xmax was a MultiXactId but it was not running anymore. There is
3325 * a race condition, which is that the MultiXactId may have finished
3326 * since then, but that uncommon case is handled within
3327 * MultiXactIdExpand.
3328 *
3329 * There is a similar race condition possible when the old xmax was a
3330 * regular TransactionId. We test TransactionIdIsInProgress again
3331 * just to narrow the window, but it's still possible to end up
3332 * creating an unnecessary MultiXactId. Fortunately this is harmless.
3333 */
3335 {
3337 {
3338 /*
3339 * If the XMAX is already a MultiXactId, then we need to
3340 * expand it to include our own TransactionId.
3341 */
3344 }
3346 {
3347 /*
3348 * If the XMAX is a valid TransactionId, then we need to
3349 * create a new MultiXactId that includes both the old locker
3350 * and our own TransactionId.
3351 */
3354 }
3355 else
3356 {
3357 /*
3358 * Can get here iff HeapTupleSatisfiesUpdate saw the old xmax
3359 * as running, but it finished before
3360 * TransactionIdIsInProgress() got to run. Treat it like
3361 * there's no locker in the tuple.
3362 */
3363 }
3364 }
3365 else
3366 {
3367 /*
3368 * There was no previous locker, so just insert our own
3369 * TransactionId.
3370 */
3371 }
3372 }
3373 else
3374 {
3375 /* We want an exclusive lock on the tuple */
3377 }
3381 /*
3382 * Store transaction information of xact locking the tuple.
3383 *
3384 * Note: Cmax is meaningless in this context, so don't set it; this avoids
3385 * possibly generating a useless combo CID.
3386 */
3390 /* Make sure there is no forward chain link in t_ctid */
3395 /*
3396 * XLOG stuff. You might think that we don't need an XLOG record because
3397 * there is no state change worth restoring after a crash. You would be
3398 * wrong however: we have just written either a TransactionId or a
3399 * MultiXactId that may never have been seen on disk before, and we need
3400 * to make sure that there are XLOG entries covering those ID numbers.
3401 * Else the same IDs might be re-used after a crash, which would be
3402 * disastrous if this page made it to disk before the crash. Essentially
3403 * we have to enforce the WAL log-before-data rule even in this case.
3404 * (Also, in a PITR log-shipping or 2PC environment, we have to have XLOG
3405 * entries for everything anyway.)
3406 */
3408 {
3409 xl_heap_lock xlrec;
3410 XLogRecPtr recptr;
3433 }
3439 /*
3440 * Don't update the visibility map here. Locking a tuple doesn't change
3441 * visibility info.
3442 */
3444 /*
3445 * Now that we have successfully marked the tuple as locked, we can
3446 * release the lmgr tuple lock, if we had it.
3447 */
3452 }
3455 /*
3456 * heap_inplace_update - update a tuple "in place" (ie, overwrite it)
3457 *
3458 * Overwriting violates both MVCC and transactional safety, so the uses
3459 * of this function in Postgres are extremely limited. Nonetheless we
3460 * find some places to use it.
3461 *
3462 * The tuple cannot change size, and therefore it's reasonable to assume
3463 * that its null bitmap (if any) doesn't change either. So we just
3464 * overwrite the data portion of the tuple without touching the null
3465 * bitmap or any of the header fields.
3466 *
3467 * tuple is an in-memory tuple structure containing the data to be written
3468 * over the target tuple. Also, tuple->t_self identifies the target tuple.
3469 */
3470 void
3472 {
3473 Buffer buffer;
3474 Page page;
3475 OffsetNumber offnum;
3477 HeapTupleHeader htup;
3478 uint32 oldlen;
3479 uint32 newlen;
3499 /* NO EREPORT(ERROR) from here till changes are logged */
3504 newlen);
3508 /* XLOG stuff */
3510 {
3511 xl_heap_inplace xlrec;
3512 XLogRecPtr recptr;
3533 }
3539 /* Send out shared cache inval if necessary */
3542 }
3545 /*
3546 * heap_freeze_tuple
3547 *
3548 * Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
3549 * are older than the specified cutoff XID. If so, replace them with
3550 * FrozenTransactionId or InvalidTransactionId as appropriate, and return
3551 * TRUE. Return FALSE if nothing was changed.
3552 *
3553 * It is assumed that the caller has checked the tuple with
3554 * HeapTupleSatisfiesVacuum() and determined that it is not HEAPTUPLE_DEAD
3555 * (else we should be removing the tuple, not freezing it).
3556 *
3557 * NB: cutoff_xid *must* be <= the current global xmin, to ensure that any
3558 * XID older than it could neither be running nor seen as running by any
3559 * open transaction. This ensures that the replacement will not change
3560 * anyone's idea of the tuple state. Also, since we assume the tuple is
3561 * not HEAPTUPLE_DEAD, the fact that an XID is not still running allows us
3562 * to assume that it is either committed good or aborted, as appropriate;
3563 * so we need no external state checks to decide what to do. (This is good
3564 * because this function is applied during WAL recovery, when we don't have
3565 * access to any such state, and can't depend on the hint bits to be set.)
3566 *
3567 * In lazy VACUUM, we call this while initially holding only a shared lock
3568 * on the tuple's buffer. If any change is needed, we trade that in for an
3569 * exclusive lock before making the change. Caller should pass the buffer ID
3570 * if shared lock is held, InvalidBuffer if exclusive lock is already held.
3571 *
3572 * Note: it might seem we could make the changes without exclusive lock, since
3573 * TransactionId read/write is assumed atomic anyway. However there is a race
3574 * condition: someone who just fetched an old XID that we overwrite here could
3575 * conceivably not finish checking the XID against pg_clog before we finish
3576 * the VACUUM and perhaps truncate off the part of pg_clog he needs. Getting
3577 * exclusive lock ensures no other backend is in process of checking the
3578 * tuple status. Also, getting exclusive lock makes it safe to adjust the
3579 * infomask bits.
3580 */
3581 bool
3583 Buffer buf)
3584 {
3586 TransactionId xid;
3591 {
3593 {
3594 /* trade in share lock for exclusive lock */
3598 }
3601 /*
3602 * Might as well fix the hint bits too; usually XMIN_COMMITTED will
3603 * already be set here, but there's a small chance not.
3604 */
3608 }
3610 /*
3611 * When we release shared lock, it's possible for someone else to change
3612 * xmax before we get the lock back, so repeat the check after acquiring
3613 * exclusive lock. (We don't need this pushup for xmin, because only
3614 * VACUUM could be interested in changing an existing tuple's xmin, and
3615 * there's only one VACUUM allowed on a table at a time.)
3616 */
3617 recheck_xmax:
3619 {
3623 {
3625 {
3626 /* trade in share lock for exclusive lock */
3631 }
3634 /*
3635 * The tuple might be marked either XMAX_INVALID or XMAX_COMMITTED
3636 * + LOCKED. Normalize to INVALID just to be sure no one gets
3637 * confused.
3638 */
3643 }
3644 }
3645 else
3646 {
3647 /*----------
3648 * XXX perhaps someday we should zero out very old MultiXactIds here?
3649 *
3650 * The only way a stale MultiXactId could pose a problem is if a
3651 * tuple, having once been multiply-share-locked, is not touched by
3652 * any vacuum or attempted lock or deletion for just over 4G MultiXact
3653 * creations, and then in the probably-narrow window where its xmax
3654 * is again a live MultiXactId, someone tries to lock or delete it.
3655 * Even then, another share-lock attempt would work fine. An
3656 * exclusive-lock or delete attempt would face unexpected delay, or
3657 * in the very worst case get a deadlock error. This seems an
3658 * extremely low-probability scenario with minimal downside even if
3659 * it does happen, so for now we don't do the extra bookkeeping that
3660 * would be needed to clean out MultiXactIds.
3661 *----------
3662 */
3663 }
3665 /*
3666 * Although xvac per se could only be set by VACUUM, it shares physical
3667 * storage space with cmax, and so could be wiped out by someone setting
3668 * xmax. Hence recheck after changing lock, same as for xmax itself.
3669 */
3670 recheck_xvac:
3672 {
3676 {
3678 {
3679 /* trade in share lock for exclusive lock */
3684 }
3686 /*
3687 * If a MOVED_OFF tuple is not dead, the xvac transaction must
3688 * have failed; whereas a non-dead MOVED_IN tuple must mean the
3689 * xvac transaction succeeded.
3690 */
3693 else
3696 /*
3697 * Might as well fix the hint bits too; usually XMIN_COMMITTED
3698 * will already be set here, but there's a small chance not.
3699 */
3703 }
3704 }
3707 }
3710 /* ----------------
3711 * heap_markpos - mark scan position
3712 * ----------------
3713 */
3714 void
3716 {
3717 /* Note: no locking manipulations needed */
3720 {
3724 }
3725 else
3727 }
3729 /* ----------------
3730 * heap_restrpos - restore position to marked location
3731 * ----------------
3732 */
3733 void
3735 {
3736 /* XXX no amrestrpos checking that ammarkpos called */
3739 {
3742 /*
3743 * unpin scan buffers
3744 */
3750 }
3751 else
3752 {
3753 /*
3754 * If we reached end of scan, rs_inited will now be false. We must
3755 * reset it to true to keep heapgettup from doing the wrong thing.
3756 */
3760 {
3763 NoMovementScanDirection,
3765 NULL);
3766 }
3767 else
3769 NoMovementScanDirection,
3771 NULL);
3772 }
3773 }
3775 /*
3776 * Perform XLogInsert for a heap-clean operation. Caller must already
3777 * have modified the buffer and marked it dirty.
3778 *
3779 * Note: prior to Postgres 8.3, the entries in the nowunused[] array were
3780 * zero-based tuple indexes. Now they are one-based like other uses
3781 * of OffsetNumber.
3782 */
3783 XLogRecPtr
3789 {
3790 xl_heap_clean xlrec;
3791 uint8 info;
3792 XLogRecPtr recptr;
3795 /* Caller should not call me on a temp relation */
3808 /*
3809 * The OffsetNumber arrays are not actually in the buffer, but we pretend
3810 * that they are. When XLogInsert stores the whole buffer, the offset
3811 * arrays need not be stored too. Note that even if all three arrays are
3812 * empty, we want to expose the buffer as a candidate for whole-page
3813 * storage, since this record type implies a defragmentation operation
3814 * even if no item pointers changed state.
3815 */
3817 {
3820 }
3821 else
3822 {
3825 }
3831 {
3834 }
3835 else
3836 {
3839 }
3845 {
3848 }
3849 else
3850 {
3853 }
3862 }
3864 /*
3865 * Perform XLogInsert for a heap-freeze operation. Caller must already
3866 * have modified the buffer and marked it dirty.
3867 */
3868 XLogRecPtr
3870 TransactionId cutoff_xid,
3872 {
3873 xl_heap_freeze xlrec;
3874 XLogRecPtr recptr;
3877 /* Caller should not call me on a temp relation */
3879 /* nor when there are no tuples to freeze */
3891 /*
3892 * The tuple-offsets array is not actually in the buffer, but pretend that
3893 * it is. When XLogInsert stores the whole buffer, the offsets array need
3894 * not be stored too.
3895 */
3905 }
3907 /*
3908 * Perform XLogInsert for a heap-update operation. Caller must already
3909 * have modified the buffer(s) and marked them dirty.
3910 */
3911 static XLogRecPtr
3914 {
3915 /*
3916 * Note: xlhdr is declared to have adequate size and correct alignment for
3917 * an xl_heap_header. However the two tids, if present at all, will be
3918 * packed in with no wasted space after the xl_heap_header; they aren't
3919 * necessarily aligned as implied by this struct declaration.
3920 */
3921 struct
3922 {
3923 xl_heap_header hdr;
3924 TransactionId tid1;
3925 TransactionId tid2;
3928 xl_heap_update xlrec;
3929 uint8 info;
3930 XLogRecPtr recptr;
3934 /* Caller should not call me on a temp relation */
3938 {
3941 }
3944 else
3968 {
3973 else
3980 }
3982 /*
3983 * As with insert records, we need not store the rdata[2] segment if we
3984 * decide to store the whole buffer instead.
3985 */
3992 /* PG73FORMAT: write bitmap [+ padding] [+ oid] + data */
3999 /* If new tuple is the single and first tuple on page... */
4002 {
4005 }
4010 }
4012 /*
4013 * Perform XLogInsert for a heap-move operation. Caller must already
4014 * have modified the buffers and marked them dirty.
4015 */
4016 XLogRecPtr
4019 {
4021 }
4023 /*
4024 * Perform XLogInsert of a HEAP_NEWPAGE record to WAL. Caller is responsible
4025 * for writing the page to disk after calling this routine.
4026 *
4027 * Note: all current callers build pages in private memory and write them
4028 * directly to smgr, rather than using bufmgr. Therefore there is no need
4029 * to pass a buffer ID to XLogInsert, nor to perform MarkBufferDirty within
4030 * the critical section.
4031 *
4032 * Note: the NEWPAGE log record is used for both heaps and indexes, so do
4033 * not do anything that assumes we are touching a heap.
4034 */
4035 XLogRecPtr
4037 Page page)
4038 {
4039 xl_heap_newpage xlrec;
4040 XLogRecPtr recptr;
4043 /* NO ELOG(ERROR) from here till newpage op is logged */
4068 }
4070 /*
4071 * Handles CLEAN and CLEAN_MOVE record types
4072 */
4073 static void
4075 {
4077 Buffer buffer;
4078 Page page;
4086 Size freespace;
4097 {
4100 }
4111 /* Update all item pointers per the record, and repair fragmentation */
4116 clean_move);
4120 /*
4121 * Note: we don't worry about updating the page's prunability hints. At
4122 * worst this will cause an extra prune cycle to occur soon.
4123 */
4130 /*
4131 * Update the FSM as well.
4132 *
4133 * XXX: We don't get here if the page was restored from full page image.
4134 * We don't bother to update the FSM in that case, it doesn't need to be
4135 * totally accurate anyway.
4136 */
4138 }
4140 static void
4142 {
4145 Buffer buffer;
4146 Page page;
4157 {
4160 }
4163 {
4171 {
4172 /* offsets[] entries are one-based */
4177 offsets++;
4178 }
4179 }
4185 }
4187 static void
4189 {
4191 Buffer buffer;
4192 Page page;
4194 /*
4195 * Note: the NEWPAGE log record is used for both heaps and indexes, so do
4196 * not do anything that assumes we are touching a heap.
4197 */
4209 }
4211 static void
4213 {
4215 Buffer buffer;
4216 Page page;
4217 OffsetNumber offnum;
4219 HeapTupleHeader htup;
4220 BlockNumber blkno;
4224 /*
4225 * The visibility map always needs to be updated, even if the heap page is
4226 * already up-to-date.
4227 */
4229 {
4234 }
4245 {
4248 }
4260 HEAP_XMAX_INVALID |
4261 HEAP_XMAX_IS_MULTI |
4262 HEAP_IS_LOCKED |
4263 HEAP_MOVED);
4268 /* Mark the page as a candidate for pruning */
4274 /* Make sure there is no forward chain link in t_ctid */
4280 }
4282 static void
4284 {
4286 Buffer buffer;
4287 Page page;
4288 OffsetNumber offnum;
4289 struct
4290 {
4291 HeapTupleHeaderData hdr;
4294 HeapTupleHeader htup;
4295 xl_heap_header xlhdr;
4296 uint32 newlen;
4297 Size freespace;
4298 BlockNumber blkno;
4302 /*
4303 * The visibility map always needs to be updated, even if the heap page is
4304 * already up-to-date.
4305 */
4307 {
4312 }
4318 {
4324 }
4325 else
4326 {
4333 {
4336 }
4337 }
4347 SizeOfHeapHeader);
4350 /* PG73FORMAT: get bitmap [+ padding] [+ oid] + data */
4353 newlen);
4377 /*
4378 * If the page is running low on free space, update the FSM as well.
4379 * Arbitrarily, our definition of "low" is less than 20%. We can't do much
4380 * better than that without knowing the fill-factor for the table.
4381 *
4382 * XXX: We don't get here if the page was restored from full page image.
4383 * We don't bother to update the FSM in that case, it doesn't need to be
4384 * totally accurate anyway.
4385 */
4388 }
4390 /*
4391 * Handles UPDATE, HOT_UPDATE & MOVE
4392 */
4393 static void
4395 {
4397 Buffer buffer;
4400 Page page;
4401 OffsetNumber offnum;
4403 HeapTupleHeader htup;
4404 struct
4405 {
4406 HeapTupleHeaderData hdr;
4409 xl_heap_header xlhdr;
4411 uint32 newlen;
4412 Size freespace;
4414 /*
4415 * The visibility map always needs to be updated, even if the heap page is
4416 * already up-to-date.
4417 */
4419 {
4425 }
4428 {
4432 }
4434 /* Deal with old tuple version */
4444 {
4449 }
4461 {
4463 HEAP_XMIN_INVALID |
4464 HEAP_MOVED_IN);
4468 /* Make sure there is no forward chain link in t_ctid */
4470 }
4471 else
4472 {
4474 HEAP_XMAX_INVALID |
4475 HEAP_XMAX_IS_MULTI |
4476 HEAP_IS_LOCKED |
4477 HEAP_MOVED);
4480 else
4484 /* Set forward chain link in t_ctid */
4486 }
4488 /* Mark the page as a candidate for pruning */
4494 /*
4495 * this test is ugly, but necessary to avoid thinking that insert change
4496 * is already applied
4497 */
4505 /* Deal with new tuple */
4507 newt:;
4509 /*
4510 * The visibility map always needs to be updated, even if the heap page is
4511 * already up-to-date.
4512 */
4514 {
4519 }
4525 {
4533 }
4534 else
4535 {
4544 {
4547 }
4548 }
4550 newsame:;
4564 SizeOfHeapHeader);
4567 /* PG73FORMAT: get bitmap [+ padding] [+ oid] + data */
4570 newlen);
4577 {
4586 }
4587 else
4588 {
4591 }
4592 /* Make sure there is no forward chain link in t_ctid */
4609 /*
4610 * If the page is running low on free space, update the FSM as well.
4611 * Arbitrarily, our definition of "low" is less than 20%. We can't do much
4612 * better than that without knowing the fill-factor for the table.
4613 *
4614 * However, don't update the FSM on HOT updates, because after crash
4615 * recovery, either the old or the new tuple will certainly be dead and
4616 * prunable. After pruning, the page will have roughly as much free space
4617 * as it did before the update, assuming the new tuple is about the same
4618 * size as the old one.
4619 *
4620 * XXX: We don't get here if the page was restored from full page image.
4621 * We don't bother to update the FSM in that case, it doesn't need to be
4622 * totally accurate anyway.
4623 */
4627 }
4629 static void
4631 {
4633 Buffer buffer;
4634 Page page;
4635 OffsetNumber offnum;
4637 HeapTupleHeader htup;
4650 {
4653 }
4665 HEAP_XMAX_INVALID |
4666 HEAP_XMAX_IS_MULTI |
4667 HEAP_IS_LOCKED |
4668 HEAP_MOVED);
4673 else
4678 /* Make sure there is no forward chain link in t_ctid */
4684 }
4686 static void
4688 {
4690 Buffer buffer;
4691 Page page;
4692 OffsetNumber offnum;
4694 HeapTupleHeader htup;
4695 uint32 oldlen;
4696 uint32 newlen;
4709 {
4712 }
4730 newlen);
4736 }
4738 void
4740 {
4746 {
4773 }
4774 }
4776 void
4778 {
4782 {
4797 }
4798 }
4800 static void
4802 {
4807 }
4809 void
4811 {
4816 {
4821 else
4824 }
4826 {
4831 }
4833 {
4838 else
4844 }
4846 {
4851 else
4857 }
4859 {
4864 else
4870 }
4872 {
4878 }
4880 {
4885 else
4889 else
4893 }
4895 {
4900 }
4901 else
4903 }
4905 void
4907 {
4912 {
4919 }
4921 {
4927 }
4929 {
4935 }
4936 else
4938 }
4940 /*
4941 * heap_sync - sync a heap, for use when no WAL has been written
4942 *
4943 * This forces the heap contents (including TOAST heap if any) down to disk.
4944 * If we skipped using WAL, and it's not a temp relation, we must force the
4945 * relation down to disk before it's safe to commit the transaction. This
4946 * requires writing out any dirty buffers and then doing a forced fsync.
4947 *
4948 * Indexes are not touched. (Currently, index operations associated with
4949 * the commands that use this are WAL-logged and so do not need fsync.
4950 * That behavior might change someday, but in any case it's likely that
4951 * any fsync decisions required would be per-index and hence not appropriate
4952 * to be done here.)
4953 */
4954 void
4956 {
4957 /* temp tables never need fsync */
4961 /* main heap */
4963 /* FlushRelationBuffers will have opened rd_smgr */
4966 /* FSM is not critical, don't bother syncing it */
4968 /* toast heap, if any */
4970 {
4971 Relation toastrel;
4977 }
4978 }