Re: [PATCH] Assert that the correct locks are held when calling PageGetLSN()

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

In response to

Responses

Browse pgsql-hackers by date

  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?