Andrew Dunstan <andrew@dunslane.net> writes:
> Yes it seems like a bug, but hard to diagnose. It seemed like a bug back
> in May: 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-2b5b894571de%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
