From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Peter Geoghegan <pg@bowt.ie>, Alexander Lakhin <exclusion@gmail.com>,
        Chao Li <li.evan.chao@gmail.com>,
        Kirill Reshke <reshkekirill@gmail.com>,
        Heikki Linnakangas <hlinnaka@iki.fi>,
        Melanie Plageman <melanieplageman@gmail.com>,
        Matthias van de Meent <boekewurm+postgres@gmail.com>,
        pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>,
        Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>,
        Michael Paquier <michael.paquier@gmail.com>
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
In-reply-to: <q2o7rfmkcvqhj7ttimno33mb7lklybj6aanliertmfr4g7g7zn@w4cat7zimc5c>
References: <cj5mcjdpucvw4a54hehslr3ctukavrbnxltvuzzhqnimvpju5e@cy3g3mnsefwz>
 <58821140-0182-4FF3-9A4F-5B168DDB9243@gmail.com>
 <732580B4-962F-4EBD-8811-F4667D79747D@gmail.com>
 <wat7azo4hpgux7ptvozfedtw6hnz7pih3vvnfipxdlcci6fuf3@wacut36qcac7>
 <934395.1768518154@sss.pgh.pa.us>
 <90bd2cbb-49ce-4092-9f61-5ac2ab782c94@gmail.com>
 <esihk6vohorlopugumy6ps6zmyh7cgkwi66trm4ocpbkqa4i2i@g5j2hvbzv4lp>
 <3472929.1769289107@sss.pgh.pa.us>
 <cf7prit6zlr64ekyf7ev4x2jxporxplcjnoq6sao3nbrpawtj7@65mndedqeqm2>
 <3496575.1769302476@sss.pgh.pa.us>
 <q2o7rfmkcvqhj7ttimno33mb7lklybj6aanliertmfr4g7g7zn@w4cat7zimc5c>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Thu, 29 Jan 2026 12:27:10 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1264179.1769718263.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Jan 2026 15:24:23 -0500
Message-ID: <1264180.1769718263@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1264180.1769718263%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> Anyway, independent of that, the behavior clearly needs to be allowed. H=
ere's
> a proposed patch.

> At first I was thinking of just removing the assertion without anything =
else
> in place - but I think that's not quite right: We could e.g. be trying t=
o
> acquire a share or share-exclusive lock when holding a share lock (or th=
e
> reverse), but we can't currently don't keep track of two different lock =
modes
> for the same lock.  Therefore it seems safer to just define it so that
> acquiring a conditional lock on a buffer that is already locked by us wi=
ll
> always fail, regardless of what existing lock mode we already hold.  I t=
hink
> all current callers good with that.

> Does that sound reasonable?

I didn't read the patch, but I agree with this description of what the
behavior should be.

> We could add support for locking the same buffer multiple times, but I d=
on't
> think it'd be worth the complexity and (small) overhead that would bring=
 with
> it?

Also agreed --- I think that's behavior we actively don't want.

> It also seems like allowing that would make it more likely for a backend
> to trample over its own state higher up in the call tree.

Precisely.

			regards, tom lane