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
