Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 23 Jul 2025 10:39:30 +0900
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
Message-ID: <aIA9UnMTsDEeo_jB@paquier.xyz>
References: <18992-b0add0a16bbf4ca9@postgresql.org>
 <CAFiTN-sVt=+hf5uYsuCBaGR76y_Ag-4WM39HAsdcOeL0iz2XWg@mail.gmail.com>
 <CAH2L28uqTCVCCSzdCXtQhNDQxKNDfB=0Ue0Z0ZXqdrK5p23XtA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="QFFwrbbTj818QIsM"
Content-Disposition: inline
In-Reply-To: 
 <CAH2L28uqTCVCCSzdCXtQhNDQxKNDfB=0Ue0Z0ZXqdrK5p23XtA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aIA9UnMTsDEeo_jB%40paquier.xyz>
Precedence: bulk


--QFFwrbbTj818QIsM
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 asse=
rt
> is triggered. I haven=E2=80=99t
> 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 helpfu=
l.

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=20
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

--QFFwrbbTj818QIsM
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmiAPVIACgkQnvQgOdby
QH2Txw//bP0/Wmp9//v+QfqEEnHBHJuvLb4ZvjD5mWZ4/nKkjGfPa3+9X42ssMbw
5YzpydGrcuutMq0EMlaPlaKq7aSclFO1i9dqFHmoAWprglREIR2D72Yc+J+iDP96
k12VYfX0OIi5PEVA/UzfYxYJKTWfX/0XsbwilF9jEcl4ebLvUX78oGOOqr7pYZLv
lZghmvSHFr96I4UKr5ou5A1eN85NOJEdrisGr2J/wKtndDXi2wBnRA/bKg/fwHVN
VyoctYo9lsbuKBt5FI+reoqlFiewA//eKGwBYv7jgizt3WDgBvc1qRA1Y/h7KOgt
bdpfPSMqTGwzg1gAT4J0tSXDvO6gSTRpj1sKKv+hYsRy15t22Ba8aWBAoRqkftiz
Hqtsw1LrnOtsR6EtpPt5Qia34H0qHBOnSp8bsb9rxAWJ59a1pD0RksmRZrRgUC24
YssFV0TBIpXa4PBaklf9wDf7/xjpdhb/L8/UMz66EoOaJdVek8dX5mOj1A4qUvXd
lQsLW3j5cnZ8TFsvqrjVMt8Wt3IF0ugJS8Ku7fDhwnV1rqA+sheimkZd45UvB+Jg
zjKRj3IuqTXBQLhinBjebOd0wJA8tksu+ss2bqgVnasYanymtjQIiPQXHFdfugcX
qpwQ7csDMr6cZZ2Fzm+1GxWFzj7jsubtOv333L7O4f02GLnMYUs=
=XedE
-----END PGP SIGNATURE-----

--QFFwrbbTj818QIsM--