From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Subject: Re: Why is lorikeet so unstable in v14 branch only?
In-reply-to: <0b9defaa-07a3-7329-4f9d-5fc2c4a89170@dunslane.net>
References: <136102.1648320427@sss.pgh.pa.us>
 <20220326194948.mksfw6z3fysojpxx@alap3.anarazel.de>
 <aee3de02-1e5d-ae0a-c3e7-23cb1ef8cd70@dunslane.net>
 <167387.1648329583@sss.pgh.pa.us>
 <0b9defaa-07a3-7329-4f9d-5fc2c4a89170@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Sat, 26 Mar 2022 17:48:39 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <174837.1648332620.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 26 Mar 2022 18:10:20 -0400
Message-ID: <174838.1648332620@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/174838.1648332620%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> Yes it seems like a bug, but hard to diagnose. It seemed like a bug back
> in May:=C2=A0 see
> <https://postgr.es/m/4baee39d-0ebe-8327-7878-5bc11c95effa@dunslane.net>

Ah, right, but that link is busted.  Here's the correct link:

https://www.postgresql.org/message-id/flat/e6f1fb3e-1e08-0188-9c71-2b5b894=
571de%40dunslane.net

> I vaguely theorize about a buffer overrun somewhere that scribbles on
> the stack.

I said in the earlier thread

> A platform-specific problem in get_ps_display() seems plausible
> enough.  The apparent connection to a concurrent VACUUM FULL seems
> pretty hard to explain that way ... but maybe that's a mirage.

but your one stack trace showed a crash while trying to lock pg_class for
ScanPgRelation, which'd potentially have blocked because of the VACUUM ---
and that'd result in a process title change, if not disabled.  So now
I feel like "something rotten in ps_status.c" is a theory that can fit
the available facts.

> If I understand correctly that you're only seeing this in v13 and
> HEAD, then it seems like bf68b79e5 (Refactor ps_status.c API)
> deserves a hard look.

I still stand by this opinion.  Can you verify which of the ps_status.c
code paths gets used on this build?

			regards, tom lane