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.  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: pg_dump dump catalog ACLs
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Removing faulty hyperLogLog merge function