From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Dan Langille <dan(at)langille(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: could not truncate directory "pg_subtrans": apparent wraparound |
Date: | 2015-07-22 22:31:55 |
Message-ID: | 55B019DB.2070705@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
repro-bogus-multixact-members-error.sh | application/x-shellscript | 900 bytes |
repro-bogus-multixact-members-error-wraparound.sh | application/x-shellscript | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-07-23 00:01:39 | Re: TABLESAMPLE patch is really in pretty sad shape |
Previous Message | Dean Rasheed | 2015-07-22 21:17:36 | Re: A little RLS oversight? |