Robert Haas wrote: > I haven't really followed this thread in depth, but I'm very nervous > about the idea that we should ever be examining the raw-xmin of a > tuple that has been marked HEAP_XMIN_FROZEN for anything other than > forensic purposes.
Yeah, me too. If you see another way to fix the problem, let's discuss it. I think a possible way is to avoid considering that the relfrozenxid value computed by the caller is final. Something like this: if page freezing sees that there is a HOT chain which would end up half-frozen because of that freeze age, decrease the freeze xid enough that the whole chain remains unfrozen; communicate the new value to caller so that it is used as the true new relfrozenxid going forwards. That preserves the HOT chain intact so that it can be pruned and frozen correctly in a later VACUUM call. Need to be careful about HOT chains containing members that are old enough to cause a long term problem (i.e. a table where relfrozenxid doesn't move forward enough). One thing I didn't quite investigate is why this bug only shows up with multixacts so far. Is it just because multixacts provide an easy way to reproduce it, and that there are others, more difficult ways to cause the same problem without involving multixacts? If so, then the problem is likely present in 9.2 as well. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
