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 1rAbhP-007Nob-BI for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Dec 2023 20:07:19 +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 1rAbgP-005rnt-Vo for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Dec 2023 20:06:17 +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 1rAbgP-005rnk-Ms for pgsql-hackers@lists.postgresql.org; Tue, 05 Dec 2023 20:06:17 +0000 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rAbgN-00AGu1-2N for pgsql-hackers@postgresql.org; Tue, 05 Dec 2023 20:06:17 +0000 Received: by mail-io1-xd34.google.com with SMTP id ca18e2360f4ac-7b3846558a7so236455439f.1 for ; Tue, 05 Dec 2023 12:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701806772; x=1702411572; darn=postgresql.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=OFUKatBowtN15Dh86kT1hU8IIOT/bqeMiFZbt76DDsQ=; b=HYnHbn5r01hBKTWullmRbQfCj5NxDJMrGxlqZPzZAKF/UtpyQlUXKFponP2W1mlS3p ki8/cE5a6d4xXebCFUD0lGDZ8WWccs51pEQ9ojeE82NzadiMt/g1PxnVQlyynJahT2Up hpQdl5zLa/TmFCnhC+PWcUfoL+S8xzVg/n/OyOaJGTML7tgB8y2ANaw40u0YEpn8mdVM 6bUx8NZvYYQusf1lDQtmGrx4nNTGtHMeWah4QDV9nQ9AmHPCAeNPsCRDgaGIT/3HLtDl t0yD1aJWmf+cycK9L1KgQo08BACTCt0RFUTsNTv3fiA+hYlzExdNdyIiNZMAiThto/2M fIEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701806772; x=1702411572; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OFUKatBowtN15Dh86kT1hU8IIOT/bqeMiFZbt76DDsQ=; b=Tbf+/PMWosxXxotjSD86DM8NUvO73Nyh/Sh7edXCY4LzWOk/2sJ8IMMqDokqQyFRup bCCEg1QMEAqYAMsyEyEzCid8vQcZw5Oei2DsovHoqEhMsbe087CmDhkM8yQqTHQ2qwyA aXVXwk97bJMcxBAbj+FvIT+Kqllu04BuNxLJLv5zOUdnBvFFgQDVGvEz9OhDNd1GGpFF QLBBOyj945AJi6gXnO1ph3M7i2c0LJiYORWRbc7LpclHDN0kQQ/emtt6lWue2jaanTh3 XGYH5sRSkVWt3GUpuQtVg2G1/qGbn0vNlhhbMMkHMcMEfq/WnNPXBRytXx1lqHr+rhyX jCeQ== X-Gm-Message-State: AOJu0YwAEh/lGGR9Ro37G2Nt4Op7y+tY2JEtuWj6i1MR7+UDUZ9ozNyt yRs+HqIVN06Cqwo1kn4djcHHBrC2iVs= X-Google-Smtp-Source: AGHT+IEV4Roqe0Zty/RhJNXbgppU/64rZ4lT9YONamznXU9L9ULjnRFjjEz8ImHLhK2FsApg+WCnqw== X-Received: by 2002:a5d:990c:0:b0:7b4:48d1:fbec with SMTP id x12-20020a5d990c000000b007b448d1fbecmr4894080iol.24.1701806772606; Tue, 05 Dec 2023 12:06:12 -0800 (PST) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id cl4-20020a0566383d0400b00468e797b71fsm2405681jab.84.2023.12.05.12.06.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 12:06:12 -0800 (PST) Date: Tue, 5 Dec 2023 14:06:10 -0600 From: Nathan Bossart To: Matthias van de Meent Cc: Robert Haas , Peter Eisentraut , pgsql-hackers Subject: Re: backtrace_on_internal_error Message-ID: <20231205200610.GA2761183@nathanxps13> References: <20231205174034.GA2757816@nathanxps13> <20231205182845.GD2757816@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Dec 05, 2023 at 07:47:25PM +0100, Matthias van de Meent wrote: > On Tue, 5 Dec 2023 at 19:30, Robert Haas wrote: >> On Tue, Dec 5, 2023 at 1:28 PM Nathan Bossart wrote: >> > Perhaps this should be a GUC that defaults to LOG or ERROR. >> >> Why? Sorry, I should've explained why in my message. > I can't speak for Nathan, but my reason would be that I'm not in the > habit to attach a debugger to my program to keep track of state > progression, but instead use elog() during patch development. I'm not > super stoked for getting my developmental elog(LOG)-s spammed with > stack traces, so I'd want to set this at least to ERROR, while in > production LOG could be fine. > > Similarly, there are probably extensions that do not use ereport() > directly, but instead use elog(), because of reasons like 'not > planning on doing translations' and 'elog() is the easier API'. > Forcing a change over to ereport because of stack trace spam in logs > caused by elog would be quite annoying. My main concern was forcing extra logging that users won't have a great way to turn off (except for maybe raising log_min_messages or something). Also, it'd give us a way to slowly ramp up backtraces over a few years without suddenly spamming everyones logs in v17. For example, maybe this GUC defaults to PANIC or FATAL in v17. Once we've had a chance to address any common backtraces there, we could bump it to ERROR or WARNING in v18. And so on. If we just flood everyone's logs immediately, I worry that folks will just turn it off, and we won't get the reports we are hoping for. I know we already have so many GUCs and would like to avoid adding new ones when possible. Maybe this is one that could eventually be retired as we gain confidence that it won't obliterate the log files. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com