On 06/13/2015 05:02 AM, Thomas Munro wrote:
Since the multixact equivalent of this problem[1] fell through the cracks on the multixact mega-thread, here is an updated patch that addresses this problem for both pg_subtrans and pg_multixact/offsets using the same approach: always step back one multixact/xid (rather than doing so only if oldest == next, which seemed like an unnecessary complication, and a bit futile since the result of such a test is only an instantaneous snapshot). I've added this to the commitfest[2]. I am also attaching a new set of repro scripts including a pair to test the case where next multixact/xid == first valid ID (the scripts with 'wraparound' in the name, which use dirty pg_resetxlog tricks to get into that situation). In my previous patch I naively subtracted one, which didn't work for those (even rarer!) cases. The new patch steps over the special ID values.
Thanks, great repro scripts!
I also took a look at the pg_clog and pg_commit_ts truncation functions. You could argue that they have the same problem in theory (they pass a page number derived from the oldest xid to SimpleLruTruncate, and maybe there is a way for that to be an xid that hasn't been issued yet), but in practice I don't think it's a reachable condition. They use the frozen xid that is updated by vacuuming, but vacuum itself advances the next xid counter in the process. Is there a path though the vacuum code that ever exposes frozen xid == next xid? In contrast, for pg_subtrans we use GetOldestXmin(), which is equal to the next xid if there are no running transactions, and for pg_multixact we use the oldest multixact, which can be equal to the next multixact ID after a wraparound vacuum because vacuum itself doesn't always consume multixacts.
Yeah, I think pg_clog and pg_commit_ts are safe, for now. It's rather accidental, though.
There is one more instance of this bug though: in 9.2 and below, pg_multixact members are truncated similarly. Attached are corresponding repro-scripts for that case.
Committed with the additional fix for that. - Heikki
repro-bogus-multixact-members-error.sh
Description: application/shellscript
repro-bogus-multixact-members-error-wraparound.sh
Description: application/shellscript
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers