Re: Improvement of procArray.xmin for VACUUM

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Well I think this would be the same infrastructure we would need to do
>> the other discussed improvement to address pg_dump's impact. That
>> would require us to publish the youngest xmax of the live
>> snapshots. Vacuum could deduce that that xid cannot possibly see any
>> transactions between the youngest extant xmax and the oldest
>> in-progress transaction.
>
> ... and do what with the knowledge? Not remove tuples, because any such
> tuples would be part of RECENTLY_DEAD update chains that that xact might
> be following now or in the future.

Well that just means it might require extra work, not that it would be
impossible.

Firstly, some tuples would not be part of a chain and could be cleaned up
anyways. Others would be part of a HOT chain which might make it easier to
clean them up.

But even for tuples that are part of a chain there may be solutions. We could
truncate the tuple to just the MVCC information so subsequent transactions can
find the head. Or we might be able to go back and edit the forward link to
skip the dead intermediate tuples (and somehow deal with the race
conditions...)

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com