From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Why is lorikeet so unstable in v14 branch only? |
Date: | 2022-03-26 22:10:20 |
Message-ID: | 174838.1648332620@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2022-03-26 22:25:36 | Re: Document atthasmissing default optimization avoids verification table scan |
Previous Message | Tomas Vondra | 2022-03-26 21:58:01 | Re: Column Filtering in Logical Replication |