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 1rFcyN-00B1zv-Th for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Dec 2023 16:29:35 +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 1rFcyM-00358m-Bq for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Dec 2023 16:29:34 +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 1rFcyM-00358d-2R for pgsql-hackers@lists.postgresql.org; Tue, 19 Dec 2023 16:29:34 +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 1rFcyJ-00Cp3O-Rr for pgsql-hackers@postgresql.org; Tue, 19 Dec 2023 16:29:33 +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 3BJGTQ98098861; Tue, 19 Dec 2023 11:29:26 -0500 From: Tom Lane To: Robert Haas cc: Andres Freund , Peter Eisentraut , 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> <1439034.1702047909@sss.pgh.pa.us> <20231208181451.deqnflwxqoehhxpe@awork3.anarazel.de> <1466396.1702059830@sss.pgh.pa.us> <20231208183440.5z2rdpojcs5h5slk@awork3.anarazel.de> Comments: In-reply-to Robert Haas message dated "Tue, 19 Dec 2023 11:11:35 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98859.1703003366.1@sss.pgh.pa.us> Date: Tue, 19 Dec 2023 11:29:26 -0500 Message-ID: <98860.1703003366@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > The last change we made in this area that, at least for me, massively > improved debuggability was the change to log the current query string > when a backend crashes. That's such a huge help; I can't imagine going > back to the old way where you had basically no idea what made things > go boom. I think doing something like this can have a similarly > positive impact. It is going to take some work - from us and from > extension authors - to tidy things up so that it doesn't produce a > bunch of unwanted output, but the payoff will be the ability to > actually find and fix the bugs instead of just saying to a customer > "hey, sucks that you hit a bug, let us know if you find a reproducer." IMO, we aren't really going to get a massive payoff from this with the current backtrace output; it's just not detailed enough. It's better than nothing certainly, but to really move the goalposts we'd need something approaching gdb's "bt full" output. I wonder if it'd be sane to try to auto-invoke gdb. That's just blue sky for now, though. In the meantime, I agree with the proposal as it stands (that is, auto-backtrace on any XX000 error). We'll soon find out whether it's useless, or needs more detail to be really helpful, or is just right as it is. Once we have some practical experience with it, we can course-correct as needed. regards, tom lane