1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-03 20:02:46 +03:00

Move remaining code from tqual.[ch] to heapam.h / heapam_visibility.c.

Given these routines are heap specific, and that there will be more
generic visibility support in via table AM, it makes sense to move the
prototypes to heapam.h (routines like HeapTupleSatisfiesVacuum will
not be exposed in a generic fashion, because they are too storage
specific).

Similarly, the code in tqual.c is specific to heap, so moving it into
access/heap/ makes sense.

Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
This commit is contained in:
Andres Freund
2019-01-21 17:03:15 -08:00
parent b7eda3e0e3
commit c91560defc
32 changed files with 65 additions and 101 deletions

View File

@ -8,9 +8,9 @@
* When a tuple is updated or deleted, our standard time qualification rules
* consider that it is *still valid* so long as we are in the same command,
* ie, until the next CommandCounterIncrement() or transaction commit.
* (See utils/time/tqual.c, and note that system catalogs are generally
* scanned under the most current snapshot available, rather than the
* transaction snapshot.) At the command boundary, the old tuple stops
* (See acces/heap/heapam_visibility.c, and note that system catalogs are
* generally scanned under the most current snapshot available, rather than
* the transaction snapshot.) At the command boundary, the old tuple stops
* being valid and the new version, if any, becomes valid. Therefore,
* we cannot simply flush a tuple from the system caches during heap_update()
* or heap_delete(). The tuple is still good at that point; what's more,