Re: Rework the way multixact truncations work - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Rework the way multixact truncations work
Date
Msg-id 20150929140912.GA2573@alvherre.pgsql
Whole thread Raw
In response to Re: Rework the way multixact truncations work  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas wrote:
> On Mon, Sep 28, 2015 at 10:48 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> > 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.
> 
> Yes.  But if the master hasn't been updated yet, then we still need to
> do something based on a calculation.

Right.

> > 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".
> 
> Panicking the standby because the master hasn't been updated does not
> seem like a good thing to me in any way.

If we had a way to force the master to upgrade, I think it would be good
because we have a mechanism to get rid of the legacy truncation code;
but as I said several messages ago this doesn't actually work which is
why I dropped the idea of panicking.

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



pgsql-hackers by date:

Previous
From: Steve Crawford
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!
Next
From: David Fetter
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!