Andres Freund wrote: > I spent some time discussing this with Robert today (with both of us > alternating between feeling the other and ourselves as stupid), and the > conclusion I think is that the problem is on the pruning, rather than > the freezing side.
Thanks both for spending some more time on this. > I think the problem is on the pruning, rather than the freezing side. We > can't freeze a tuple if it has an alive predecessor - rather than > weakining this, we should be fixing the pruning to not have the alive > predecessor. I gave a look at HTSV back then, but I didn't find what the right tweak was, but then I only tried changing the return value to DEAD and DELETE_IN_PROGRESS; the thought of selecting DEAD or RECENTLY_DEAD based on OldestXmin didn't occur to me ... I was thinking that the fact that there were live lockers meant that the tuple could not be removed, obviously failing to notice that the subsequent versions of the tuple would be good enough. > If the update xmin is actually below the cutoff we can remove the tuple > even if there's live lockers - the lockers will also be present in the > newer version of the tuple. I verified that for me that fixes the > problem. Obviously that'd require some comment work and more careful > diagnosis. Sounds good. I'll revert those commits then, keeping the test, and then you can commit your change. OK? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
