Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nYWGp-0002qD-38 for pgsql-hackers@arkaria.postgresql.org; Sun, 27 Mar 2022 17:01:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nYWGn-0006Wq-Js for pgsql-hackers@arkaria.postgresql.org; Sun, 27 Mar 2022 17:01:37 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nYWGn-0006Wh-8O for pgsql-hackers@lists.postgresql.org; Sun, 27 Mar 2022 17:01:37 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nYWGk-0000Um-W8 for pgsql-hackers@lists.postgresql.org; Sun, 27 Mar 2022 17:01:36 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 22RH1VdK380709; Sun, 27 Mar 2022 13:01:31 -0400 From: Tom Lane To: Andrew Dunstan cc: Andres Freund , pgsql-hackers@lists.postgresql.org Subject: Re: Why is lorikeet so unstable in v14 branch only? In-reply-to: <278381.1648398683@sss.pgh.pa.us> References: <136102.1648320427@sss.pgh.pa.us> <20220326194948.mksfw6z3fysojpxx@alap3.anarazel.de> <167387.1648329583@sss.pgh.pa.us> <0b9defaa-07a3-7329-4f9d-5fc2c4a89170@dunslane.net> <174838.1648332620@sss.pgh.pa.us> <278381.1648398683@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sun, 27 Mar 2022 12:31:23 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <380707.1648400491.1@sss.pgh.pa.us> Date: Sun, 27 Mar 2022 13:01:31 -0400 Message-ID: <380708.1648400491@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Andrew Dunstan 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