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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
