Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> 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.
Hm, right. In the normal vacuum case this isn't an issue because all
older versions of the row must be dead too, and so there can't be anyone
trying to chase up to the chain end from those versions. But a rule
such as I suggested above could try to remove tuples whose ancestor is
still live (to somebody).
regards, tom lane
