Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
Дата
Msg-id 20160427155140.ispvjwk3y7vibjb2@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pgindent
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pgindent