On 9/27/15 2:25 PM, Andres Freund wrote:
> 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.
Ahh, right. Which in this case stinks, because WARNING is a lot more
attention grabbing than LOG. :/
>> 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.
There was discussion about making this a PANIC instead of a LOG, which I
think is a good idea... but then there'd need to be some way to not
PANIC if you were doing an upgrade.
>> + 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.
Oh, I thought once that was set it would stay set. NM.
>> - 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?
I thought removing DetermineSafeOldestOffset was just an optimization,
but I guess I was confused.
--
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