Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()
Date
Msg-id CAB7nPqRJtKO5NLZZis3xxzH05sdAodG39qFdLQRg371Pi94PzQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()
Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()
List 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 by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: [HACKERS] 64-bit queryId?
Next
From: Nico Williams
Date:
Subject: Re: [HACKERS] generated columns