On 9/23/15 1:48 PM, Andres Freund wrote:
Honestly, I wonder whether this message
>                    ereport(LOG,
>                                    (errmsg("performing legacy multixact 
>                                     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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to