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:
6
src/backend/utils/cache/inval.c
vendored
6
src/backend/utils/cache/inval.c
vendored
@ -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,
|
||||
|
Reference in New Issue
Block a user