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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
