Re: Why is lorikeet so unstable in v14 branch only? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why is lorikeet so unstable in v14 branch only?
Date
Msg-id 380708.1648400491@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why is lorikeet so unstable in v14 branch only?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why is lorikeet so unstable in v14 branch only?  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
I wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> And maybe there's a good case for also
>> surrounding some of the code in WaitOnLock() with "if (len) ..."

> +1.  I'll make it so, and check the other callers too.

I had second thoughts about that part after realizing that callers
cannot tell the difference between "ps_display is disabled" and
"the activity part of the display is currently empty".  In the latter
case I think we'd rather have WaitOnLock still append " waiting";
and it's not like PS_USE_NONE is so common as to be worth optimizing
for.  (Else we'd have identified this problem sooner.)

> Once I push this, you should remove the update_process_title hack
> from lorikeet's config, since that was just a workaround until
> we tracked down the problem, which I think we just did.

Minimal fix pushed, so please adjust that animal's config.

            regards, tom lane



pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Document atthasmissing default optimization avoids verification table scan
Next
From: Tom Lane
Date:
Subject: Re: Add pg_freespacemap extension sql test