Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE. - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
Date
Msg-id 20160415203703.GA451837@alvherre.pgsql
Whole thread Raw
In response to Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.  (Andres Freund <andres@anarazel.de>)
Responses Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.  (Michael Paquier <michael.paquier@gmail.com>)
Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund wrote:
> On 2016-04-15 15:26:17 -0400, Tom Lane wrote:
> > I think the bottom line is that we misdesigned the WAL representation
> > by assuming that this sort of info could always be piggybacked on a
> > transaction commit record.  It's time to fix that.
> 
> I think we got to piggyback it onto a commit record, as long as there's
> one. Otherwise it's going to be more complex (queuing messages when
> reading an inval record) and slower (more wal records).  I can easily
> develop a patch for that, the question is what we do on the back
> branches...

We have introduced new wal records in back branches previously --
nothing new (c.f. 8e9a16ab8f7f0e5813644975cc3f336e5b064b6e).  The user
just needs to make sure to upgrade the standbys first.  If they don't,
they would die upon replay of the first such record, which they can take
as an indication that they need to be upgraded; the standby is down for
some time, but there is no data loss or corruption.

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
Next
From: Tom Lane
Date:
Subject: Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.