Re: Inadequate thought about buffer locking during hot standby replay

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inadequate thought about buffer locking during hot standby replay
Дата
Msg-id 5730.1352753623@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inadequate thought about buffer locking during hot standby replay  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Inadequate thought about buffer locking during hot standby replay  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
Here's an updated patch that fixes the GIST replay functions as well as
the other minor issues that were mentioned.  Barring objections, I'll
set about back-patching this as far as 9.0.

One thing that could use verification is my fix for
gistRedoPageSplitRecord.  AFAICS, the first page listed in the WAL
record is always the "original" page, and the ones following it are
pages that were split off from it, and can (as yet) only be reached by
following right-links from the "original" page.  As such, it should be
okay to release locks on the non-first pages as soon as we've written
them.  We have to hold lock on the original page though to avoid letting
readers follow dangling right-links.  Also, the update of
NSN/FOLLOW_RIGHT on the child page (if any) has to be done atomically
with all this, so that has to be done before releasing the original-page
lock as well.  Does that sound right?

            regards, tom lane


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Inadequate thought about buffer locking during hot standby replay
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Further pg_upgrade analysis for many tables