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