From: Andy Fan <zhihuifan1213@163.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <tmunro@postgresql.org>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: the s_lock_stuck on perform_spin_delay
Date: Mon, 08 Jan 2024 10:41:01 +0800
Message-ID: <871qaso7ub.fsf@163.com> (raw)
In-Reply-To: <20240104225403.dgmbbfffmm3srpgq@awork3.anarazel.de>
References: <87plyhvama.fsf@163.com>
<CA+Tgmob=RA_y4shbtodwRRhC9uwDSWnBHY=3EvnJ_txtAWoD9A@mail.gmail.com>
<489987.1704381735@sss.pgh.pa.us>
<CA+Tgmoa=q9KZ-2u8Cx35D_7HSa8YKzvfA5ffvd876_UZ2LEU3Q@mail.gmail.com>
<498328.1704386013@sss.pgh.pa.us>
<CA+TgmoaA2uqsozTj9UDNrXTKWiUz1kW9eQsKiCr9ZvPwaFGFDA@mail.gmail.com>
<20240104225403.dgmbbfffmm3srpgq@awork3.anarazel.de>
Hi!
>
> I think we should add cassert-only infrastructure tracking whether we
> currently hold spinlocks, are in a signal handler and perhaps a few other
> states. That'd allow us to add assertions like:
..
> - no lwlocks or ... while in signal handlers
I *wish* lwlocks should *not* be held while in signal handlers since it
inspired me for a direction of a low-frequency internal bug where a
backend acuqire a LWLock when it has acuqired it before. However when I
read more document and code, I am thinking this should not be a
problem.
per: src/backend/storage/lmgr/README
"""
LWLock manager will automatically release held LWLocks during elog()
recovery, so it is safe to raise an error while holding LWLocks.
"""
The code shows us after we acquire a LWLock, such information will be
added into a global variable named held_lwlocks, and whenever we want to
release all the them, we can just call LWLockReleaseAll.
LWLockReleaseAll is called in AbortTransaction, AbortSubTransaction,
ProcKill, AuxiliaryProcKill and so on. the code is same with what the
README said. So suppose we have some codes like this:
LWLockAcquire(...);
CHECK_FOR_INTERRUPTS();
LWLockRelease();
Even we got ERROR/FATAL in the CHECK_FOR_INTERRUPTS, I think the LWLock
are suppose to be released because of the above statement. Am I missing
anything?
--
Best Regards
Andy Fan
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: zhihuifan1213@163.com, andres@anarazel.de, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, tmunro@postgresql.org, pgsql-hackers@lists.postgresql.org
Subject: Re: the s_lock_stuck on perform_spin_delay
In-Reply-To: <871qaso7ub.fsf@163.com>
* 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