Re: Why is lorikeet so unstable in v14 branch only?

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2022-03-27T13:42:05Z
Lists: pgsql-hackers
On 3/26/22 18:10, Tom Lane wrote:
>
>> 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?
>
> 			



It appears that it is using PS_USE_NONE, as it doesn't have any of the
defines required for the other paths. I note that the branch for that in
get_ps_display() doesn't set *displen, which looks a tad suspicious. It
could be left with any old junk. And maybe there's a good case for also
surrounding some of the code in WaitOnLock() with "if (len) ..."


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




Commits

  1. Fix breakage of get_ps_display() in the PS_USE_NONE case.