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

From Jacob Champion
Subject Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()
Date
Msg-id CABAq_6Fii3b8-Wizq-C=wOw=2q_Xy+2U59Kp-NUZ7_JHUfdb3w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Tue, Nov 7, 2017 at 9:26 AM, Jacob Champion <pchampion@pivotal.io> wrote:
> On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> It seems to me that 0001 is good for a committer lookup, that will get
>> rid of all existing bugs. For 0002, what you are proposing is still
>> not a good idea for anything using page copies.
>
> I think there is still significant confusion here. To be clear: this
> patch is intended to add no changes for local page copies.

Maybe a better way to put this is: we see no failures with the
pageinspect regression tests, which exercise PageGetLSN() via the
page_header() function. Are there other tests we should be paying
attention to that might show a problem with our local-copy logic?

--Jacob


-- 
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: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Small improvement to compactify_tuples
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Small improvement to compactify_tuples