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

From Andres Freund
Subject Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
Date
Msg-id 20160427155140.ispvjwk3y7vibjb2@alap3.anarazel.de
Whole thread Raw
In response to Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2016-04-27 14:27:33 +0900, Michael Paquier wrote:
> On Wed, Apr 27, 2016 at 12:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > In other words, I think Masahiko Sawada's patch in the original post
> > is pretty much right on target, except that we don't need to do that
> > always, but rather only in the FPI case when the call to
> > visibilitymap_pin() is being optimized away.  If we solve the problem
> > that way, I don't think we even need a new WAL record for this case,
> > which is a non-trivial fringe benefit.
> 
> The visibility map is not the only thing that need to be addressed,
> no?

If I understand Robert correctly his point is about fixing the smgr
inval alone - without the invalidation fix that'd not be enough because
the relcache info with outdated information (particularly relallvisible
et al), would continue to be valid. Relcache invalidations imply an smgr
one, but not the other way round.

The reason the fix for nmsg > 0 && !markXidCommitted isn't entirely
sufficient is because the smgr invalidation isn't transaction bound,
i.e. sent out immediately. So, to have the same behaviour on master/HS,
we need a way to send out the invalidiation properly in lockstep with
replay.

- Andres



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pgindent
Next
From: Robert Haas
Date:
Subject: Re: pgindent