From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jacob Champion <pchampion(at)pivotal(dot)io>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Assert that the correct locks are held when calling PageGetLSN() |
Date: | 2017-10-02 15:05:46 |
Message-ID: | CAB7nPqRJtKO5NLZZis3xxzH05sdAodG39qFdLQRg371Pi94PzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 2, 2017 at 11:44 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Oct 2, 2017 at 10:19 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nico Williams | 2017-10-02 15:23:41 | Re: generated columns |
Previous Message | Joshua D. Drake | 2017-10-02 15:02:48 | Re: 64-bit queryId? |