Re: Rework the way multixact truncations work

Andres Freund wrote:
> On 2015-09-23 15:03:05 -0300, Alvaro Herrera wrote:

> > 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).
>
> Huh? The behaviour in that case is still better than what we have in
> 9.3+ today (not delayed till the restartpoint). Don't see why that
> should be a panic. That'd imo make it pretty much impossible to upgrade
> a pair of primary/master where you normally upgrade the standby first?
>
> This is all moot given Robert's objection to backpatching this to
> 9.3/4.

I think we need to make a decision here. Is this a terribly serious
bug/misdesign that needs addressing? If so, we need to backpatch. If
not, then by all means lets leave it alone. I don't think it is a good
idea to leave it open if we think it's serious, which is what I think is
happening.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services