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.
|
Список | 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 по дате отправления: