From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Atomic operations within spinlocks
Date: Thu, 04 Jun 2020 15:07:34 -0400
Message-ID: <1256701.1591297654@sss.pgh.pa.us> (raw)
In-Reply-To: <20200604185525.wuyjtkluppj4eddr@alap3.anarazel.de>
References: <1141819.1591208385@sss.pgh.pa.us>
<20200603204542.reuladbmgmjqzoi6@alap3.anarazel.de>
<1253593.1591293439@sss.pgh.pa.us>
<20200604185525.wuyjtkluppj4eddr@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> I'd still like to know which problem we're actually trying to solve
> here. I don't understand the "error" issues you mentioned upthread.
If you error out of getting the inner spinlock, the outer spinlock
is stuck, permanently, because there is no mechanism for spinlock
release during transaction abort. Admittedly it's not very likely
for the inner acquisition to fail, but it's possible. Aside from
timeout scenarios (e.g., process holding lock gets swapped out to
Timbuktu), it could be that both spinlocks are mapped onto a single
implementation lock by spin.c, which notes
* We map all spinlocks onto a set of NUM_SPINLOCK_SEMAPHORES semaphores.
* It's okay to map multiple spinlocks onto one semaphore because no process
* should ever hold more than one at a time.
You've falsified that argument ... and no, I don't want to upgrade
the spinlock infrastructure enough to make this OK. We shouldn't
ever be holding spinlocks long enough, or doing anything complicated
enough inside them, for such an upgrade to have merit.
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, pgsql-hackers@lists.postgresql.org
Subject: Re: Atomic operations within spinlocks
In-Reply-To: <1256701.1591297654@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