On 9/28/15 8:49 PM, Robert Haas wrote:
If at some point we back-patch this further, then it potentially
becomes a live issue, but I would like to respectfully inquire what
exactly you think making it a PANIC would accomplish? There are a lot
of scary things about this patch, but the logic for deciding whether
to perform a legacy truncation is solid as far as I know.
Maybe I'm confused, but I thought the whole purpose of this was to get
rid of the risk associated with that calculation in favor of explicit
truncation boundaries in the WAL log.
Even if that's not the case, ISTM that being big and in your face about
a potential data corruption bug is a good thing, as long as the DBA has
a way to "hit the snooze button".
Either way, I'm not going to make a fuss over it.
Just to make sure we're on the same page; Alvaro's original comment was:
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).
--
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
