MIME-Version: 1.0
References: <fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff>
 <CA+TgmoY6_-LcmkSYwKR2F=+vhr_Z3LYxATrnwioWPSNUjSy6=g@mail.gmail.com>
 <fumdcye25kkobwrjfb6d7m52gvlpzbvomr4onm6nsbcbrv24jg@fqydosoppg4l>
 <20250827001449.fb.nmisch@google.com>
In-Reply-To: <20250827001449.fb.nmisch@google.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Wed, 27 Aug 2025 10:03:08 -0400
Message-ID: 
 <CA+TgmoYY=w7QGoVnnTLU5p+6jKoAJsOmbvSsgWOiFqSjZAwO3Q@mail.gmail.com>
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
To: Noah Misch <noah@leadboat.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org,
	Melanie Plageman <melanieplageman@gmail.com>,
 Thomas Munro <thomas.munro@gmail.com>,
	Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoYY%3Dw7QGoVnnTLU5p%2B6jKoAJsOmbvSsgWOiFqSjZAwO3Q%40mail.gmail.com>
Precedence: bulk

On Tue, Aug 26, 2025 at 8:14=E2=80=AFPM Noah Misch <noah@leadboat.com> wrot=
e:
> > > AFAIK "share exclusive" or "SX" is standard terminology.
>
> Can you say more about that?

Looks like I was misremembering. I was thinking of Gray & Reuter,
Transaction Processing: Concepts and Techniques, 1993. However,
opening it up, I find that his vocabulary is slightly different. He
offers the following six lock modes: IS, IX, S, SIX, Update, X. "I"
means "intent" and acts as a modifier to the letter that follows.
Hence, SIX means "a course-granularity shared lock with intent to set
finer-granularity exclusive locks" (p. 408). His lock manager is
hierarchical, so taking a SIX lock on a table means that you are
allowed to read all the rows in the table and you are allowed to
exclusive-lock individual rows as desired and nobody is allowed to
exclusive-lock any rows in the table. It is compatible only with IS;
that is, it does not preclude other people from share-locking
individual rows (which might delay your exclusive locks on those
rows). Since we don't have intent-locking in PostgreSQL, I think my
brain mentally flattened this hierarchy down to S, X, SX, but that's
not what he actually wrote.

His "Update" locks are also somewhat interesting: an update lock is
exactly like an exclusive lock except that it permits PAST
share-locks. You take an update lock when you currently need a
share-lock but anticipate the possibility of needing an
exclusive-lock. This is a deadlock avoidance strategy: updaters will
take turns, and some of them will ultimately want exclusive locks and
others won't, but they can't deadlock against each other as long as
they all take "Update" locks initially and don't try to upgrade to
that level later. An updater's attempt to upgrade to an exclusive lock
can still be delayed by, or deadlock against, share lockers, but those
typically won't try to higher lock levels later.

If we were to use the existing PostgreSQL naming convention, I think
I'd probably argue that the nearest parallel to this level is
ShareUpdateExclusive: a self-exclusive lock level that permits
ordinary table access to continue while blocking exclusive locks, used
for an in-flight maintenance operation. But that's arguable, of
course.

--=20
Robert Haas
EDB: http://www.enterprisedb.com