Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
От | Michael Paquier |
---|---|
Тема | Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE. |
Дата | |
Msg-id | CAB7nPqTesAFgssRpRv--NrB39xfa34-+eijULwvXxMUBWWEZyA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
|
Список | pgsql-hackers |
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? For example take this report from Dmitry Vasilyev of a couple of months back where index relations are not visible on a standby: http://www.postgresql.org/message-id/CAB-SwXY6oH=9twBkXJtgR4UC1NqT-vpYAtxCseME62ADwyK5OA@mail.gmail.com This is really leading to a solution where we need to take a more general approach to this problem instead of trying to patch multiple WAL replay code paths. And Andres' stuff does so. -- Michael
В списке pgsql-hackers по дате отправления: