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


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

Reply via email to