From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Alexander Lakhin <exclusion@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Melanie Plageman <melanieplageman@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
Date: Thu, 29 Jan 2026 15:24:23 -0500
Message-ID: <1264180.1769718263@sss.pgh.pa.us> (raw)
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>
Andres Freund <andres@anarazel.de> writes:
> Anyway, independent of that, the behavior clearly needs to be allowed. Here'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 to
> acquire a share or share-exclusive lock when holding a share lock (or the
> 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 will
> always fail, regardless of what existing lock mode we already hold. I think
> 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 don'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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, pg@bowt.ie, exclusion@gmail.com, li.evan.chao@gmail.com, reshkekirill@gmail.com, hlinnaka@iki.fi, melanieplageman@gmail.com, boekewurm+postgres@gmail.com, thomas.munro@gmail.com, noah@leadboat.com, robertmhaas@gmail.com, michael.paquier@gmail.com
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
In-Reply-To: <1264180.1769718263@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox