Re: Rework the way multixact truncations work - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Rework the way multixact truncations work
Date
Msg-id 20150927192553.GA27495@awork2.anarazel.de
Whole thread Raw
In response to Re: Rework the way multixact truncations work  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Rework the way multixact truncations work  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On 2015-09-27 14:21:08 -0500, Jim Nasby wrote:
> IMHO doing just a log of something this serious; it should at least be a
> WARNING.

In postgres LOG, somewhat confusingly, is more severe than 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?

I don't understand this concern - that's just the situation we have in
all released branches today.

> +    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...)

It'll just to do legacy truncation again - without a restart on the
standby required.

> -    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?

What do you mean? This can't just isolated be left alone?



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Rework the way multixact truncations work
Next
From: Gavin Wahl
Date:
Subject: BRIN indexes for MAX, MIN, ORDER BY?