From: Michael Paquier <michael@paquier.xyz>
To: Rahila Syed <rahilasyed90@gmail.com>
Cc: tharakan@gmail.com, pgsql-bugs@lists.postgresql.org, Dilip Kumar <dilipbalaut@gmail.com>
Subject: Re: BUG #18992: Autovacuum triggering assert - LWLockAnyHeldByMe
Date: Wed, 23 Jul 2025 10:39:30 +0900
Message-ID: <aIA9UnMTsDEeo_jB@paquier.xyz> (raw)
In-Reply-To: <CAH2L28uqTCVCCSzdCXtQhNDQxKNDfB=0Ue0Z0ZXqdrK5p23XtA@mail.gmail.com>
References: <18992-b0add0a16bbf4ca9@postgresql.org>
<CAFiTN-sVt=+hf5uYsuCBaGR76y_Ag-4WM39HAsdcOeL0iz2XWg@mail.gmail.com>
<CAH2L28uqTCVCCSzdCXtQhNDQxKNDfB=0Ue0Z0ZXqdrK5p23XtA@mail.gmail.com>
On Mon, Jul 21, 2025 at 12:51:14PM +0530, Rahila Syed wrote:
> This appears to be a valid issue where the Autovacuum worker fails while
> already holding an
> LWLock on one of the pgStatLocal.shared_hash partitions. As a result, when
> we attempt to
> access this table again during proc_exit cleanup in dshash_find, the assert
> is triggered. I haven’t
> yet checked exactly where the lock is acquired within the Autovacuum
> worker, but as Dilip mentioned,
> reviewing where the error occurs in the Autovacuum worker would be helpful.
Per dsm_attach@dsm.c, about the original FATAL message "can't attach
the same segment more than once" that triggers the assertion
afterwards:
* If you're hitting this error, you probably want to attempt to find an
* existing mapping via dsm_find_mapping() before calling dsm_attach() to
* create a new one.
One thing that we could do is to upgrade this FATAL to a PANIC, to get
an idea of the stack where the original problem happens.
The stack is referencing a backend-level stats getting dropped by an
autovacuum worker as a result of pgstat_drop_entry() done in
pgstat_shutdown_hook(), so it looks like we are reaching a new error
state in v18 that could not happen before within the DSM, as an after
effect of the FATAL causing the autovacuum worker to stop. Never seen
this one. We're already doing stats reports in the
pgstat_report_stat() call with manipulations of the pgstats
dshash while shutting down.
objid at 5015 means that the procnum is set as such. How many
max_connections do you have? It seems like a high number points to a
better reproducibility.
Robins, is that your host with gcc experimental? Could it be possible
to re-run the test with a patched build with the FATAL upgraded to
PANIC and see what happens?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../aIA9UnMTsDEeo_jB@paquier.xyz/2-signature.asc)
download
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-bugs@postgresql.org
Cc: michael@paquier.xyz, rahilasyed90@gmail.com, dilipbalaut@gmail.com
Subject: Re: BUG #18992: Autovacuum triggering assert - LWLockAnyHeldByMe
In-Reply-To: <aIA9UnMTsDEeo_jB@paquier.xyz>
* 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