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