Tom Lane wrote:
> The correct question to ask is whether we could
> vacuum away the older elements of the HOT chain on the grounds that they
> are no longer of interest. What we would see is tuples with xmin equal
> to xmax and cmin different from cmax. The problem then is to determine
> whether there are any live snapshots with curcid between cmin and cmax.
> There is 0 hope of doing that from outside the originating backend.
> Now if heap_page_prune() is being run by the same backend that generated
> the in-doubt tuples, which I will agree is likely in a case like this,
> in principle we could do it.
There's an extra hurdle in the way: If you remove tuples in the middle
of an update chain (not necessarily a HOT update chain), the latest
tuple becomes inaccessible to other transactions running in read
committed mode that might need to find the latest version of the row by
following the ctid pointers.
That's not an issue if the row was created in the same transaction too,
but we don't know that in HeapTupleSatisfiesVacuum.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
