Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()
Дата
Msg-id CAB7nPqRJtKO5NLZZis3xxzH05sdAodG39qFdLQRg371Pi94PzQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Oct 2, 2017 at 11:44 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Oct 2, 2017 at 10:19 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> So those bits could be considered for integration.
>
> Yes, and they also tend to suggest that the rest of the patch has value.

Well, there are cases where you don't need any locking checks, and the
proposed patch ignores that. Take for example pageinspect which works
on a copy of a page, or just WAL replay which serializes everything,
and in both cases PageGetLSN can be used safely. So for compatibility
reasons I think that PageGetLSN should be kept alone to not surprise
anybody using it, or at least an equivalent should be introduced. It
would be interesting to make BufferGetLSNAtomic hold tighter checks,
like something that makes use of LWLockHeldByMe for example.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: [HACKERS] 64-bit queryId?
Следующее
От: Nico Williams
Дата:
Сообщение: Re: [HACKERS] generated columns