Re: Rework the way multixact truncations work

On 9/23/15 1:48 PM, Andres Freund wrote:
>> Honestly, I wonder whether this message
>> >            ereport(LOG,
>> >                    (errmsg("performing legacy multixact truncation"),
>> >                     errdetail("Legacy truncations are sometimes performed when replaying WAL from an older
primary."),
>> >                     errhint("Upgrade the primary, it is susceptible to data corruption.")));
>> >shouldn't rather be a PANIC.  (The main reason not to, I think, is that
>> >once you see this, there is no way to put the standby in a working state
>> >without recloning).
> Huh? The behaviour in that case is still better than what we have in
> 9.3+ today (not delayed till the restartpoint). Don't see why that
> should be a panic. That'd imo make it pretty much impossible to upgrade
> a pair of primary/master where you normally upgrade the standby first?

IMHO doing just a log of something this serious; it should at least be a 
WARNING.

I think the concern about upgrading a replica before the master is 
valid; is there some way we could over-ride a PANIC when that's exactly 
what someone is trying to do? Check for a special file maybe?

+    bool        sawTruncationInCkptCycle;
What happens if someone downgrades the master, back to a version that no 
longer logs truncation? (I don't think assuming that the replica will 
need to restart if that happens is a safe bet...)

-    if (MultiXactIdPrecedes(oldestMXact, earliest))
+    /* If there's nothing to remove, we can bail out early. */
+    if (MultiXactIdPrecedes(oldestMulti, earliest))     {
-        DetermineSafeOldestOffset(oldestMXact);
+        LWLockRelease(MultiXactTruncationLock);
If/when this is backpatched, would it be safer to just leave this alone?
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com