Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rBcPk-00BaHb-Mv for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Dec 2023 15:05:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rBcPj-008pq1-8I for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Dec 2023 15:05:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rBcPi-008ppt-Uw for pgsql-hackers@lists.postgresql.org; Fri, 08 Dec 2023 15:05:14 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rBcPg-00ApDr-LG for pgsql-hackers@postgresql.org; Fri, 08 Dec 2023 15:05:14 +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 3B8F59mC1439035; Fri, 8 Dec 2023 10:05:09 -0500 From: Tom Lane To: Peter Eisentraut cc: pgsql-hackers Subject: Re: backtrace_on_internal_error In-reply-to: References: <93f32d1a-9309-48dc-9b7f-c110c4d48126@eisentraut.org> <1266459.1701958930@sss.pgh.pa.us> Comments: In-reply-to Peter Eisentraut message dated "Fri, 08 Dec 2023 14:21:32 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1439033.1702047909.1@sss.pgh.pa.us> Date: Fri, 08 Dec 2023 10:05:09 -0500 Message-ID: <1439034.1702047909@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > Here is a patch to play with. Didn't read the patch yet, but ... > One possible question for discussion is whether the default for this > should be off, on, or possibly something like on-in-assert-builds. > (Personally, I'm happy to turn it on myself at run time, but everyone > has different workflows.) ... there was already opinion upthread that this should be on by default, which I agree with. You shouldn't be hitting cases like this commonly (if so, they're bugs to fix or the errcode should be rethought), and the failure might be pretty hard to reproduce. I'm not really sold that we even need YA GUC, for that matter. How about committing the behavior without a GUC, and then back-filling one if we get pushback? regards, tom lane