MultiXact truncation, startup et al.

Hi,

Heikki's comments about StartupMultiXact() being executed too late in
http://archives.postgresql.org/message-id/528C9392.8000004%40vmware.com
made me look at how multixact truncation works, since that's where
SimpleLruTruncate() would trigger an error because of an unitialized
latest_page_number.

Turns out, we don't ever truncate pg_multixact during recovery since
9dc842f0832fd71eda826349a0c17ecf8ae93b84 because multixact truncations,
in contrast to clog, aren't WAL logged themselves. Disabling probably
was fair game back then since it wasn't too likely to remain in crash
recovery forever.
But at the very least since the addition of Hot Standby that's really
not the case anymore. If I calculate correctly currently you'd end up
with ~34GB(<9.3)/38GB of pg_multixact which seems a bit much.

I am not 100% sure, but it looks like things could actually continue to
work despite having an slru wraparound into existing data. But that's
certainly nothing I'd want to rely on and looks mostly like lucky
happenstance, especially in 9.3.

If this were a master only issue, I'd say WAL-logging mxact truncation
would be the way to go, but we can't really do that in the back branches
since multixact_redo() would throw a fit if we were to introduce a new
type of wal record and somebody would upgrade a primary first.

So, what I think we need to do is to split StartupMultiXact() into two
parts, StartupMultiXact() which only sets the offset's, members's
shared->latest_page_number and TrimMultiXact() which does the remainder
of the work, executed when finishing crash recovery at the current
location of StartupMultiXact().

At this point <9.3 and 9.3+ diverge:

<9.3 we can just re-enable doing TruncateMultiXact() in
CheckPointMultiXact() since the content of the mxacts isn't important
anymore - we just need the WAL records to be sure to have advanced the
nextMXact, nextOffset counters to be sure they are big enough.

>= 9.3 multixact checkpoints don't actually perform the truncation
anymore, but vacuum does, via vac_truncate_clog(). Which obviously isn't
executed during recovery. So we need to re-add truncation there,
possibly only during recovery (everything else should be superflous
work)?

Any comments?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services