Re: could not truncate directory "pg_subtrans": apparent wraparound

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