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