Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1df7LE-0000CJ-Qm for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Aug 2017 16:26:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1df7LE-0002Tm-7Q for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Aug 2017 16:26:48 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1df7LB-0002SI-RN for pgsql-hackers@postgresql.org; Tue, 08 Aug 2017 16:26:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1df7L5-0003hy-4P for pgsql-hackers@postgresql.org; Tue, 08 Aug 2017 16:26:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v78GQala006300; Tue, 8 Aug 2017 12:26:36 -0400 From: Tom Lane To: Robert Haas cc: Jeevan Chalke , PostgreSQL Hackers Subject: Re: Server crash (FailedAssertion) due to catcache refcount mis-handling In-reply-to: References: <4244.1502206577@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 08 Aug 2017 11:54:26 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6298.1502209596.1@sss.pgh.pa.us> Date: Tue, 08 Aug 2017 12:26:36 -0400 Message-ID: <6299.1502209596@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Tue, Aug 8, 2017 at 11:36 AM, Tom Lane wrote: >> We could respond to this by using PG_ENSURE_ERROR_CLEANUP there instead >> of plain PG_TRY. But I have an itchy feeling that there may be a lot >> of places with similar issues. Should we be revisiting the basic way >> that elog(FATAL) works, to make it less unlike elog(ERROR)? > ... Arguably, this assertion is merely overzealous; we could skip > this processing when proc_exit_inprogress, for example. Yeah, I thought about weakening the assertions too, but I couldn't see a fix of that kind that didn't seem mighty ad-hoc. Now, there is some room to argue that AtEOXact_CatCache() is just obsolete and we should remove it altogether; I don't think it's caught a real bug since we invented resowners in 8.1. Short of that, though, I'm not really happy with just arbitrarily weakening the checks. But, again, the larger question to my mind is where else we may have similar issues. There's certainly never been any methodical attempt to see whether elog(FATAL) will work everywhere. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers