Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hxXZi-0007Dz-RM for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Aug 2019 14:14:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hxXZh-0003pq-5Z for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Aug 2019 14:14:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hxXZg-0003oD-QF for pgsql-hackers@lists.postgresql.org; Tue, 13 Aug 2019 14:14:56 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1hxXZe-0006Tz-GK for pgsql-hackers@postgresql.org; Tue, 13 Aug 2019 14:14:55 +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 x7DEEpPS000993; Tue, 13 Aug 2019 10:14:51 -0400 From: Tom Lane To: Peter Eisentraut cc: pgsql-hackers , Alvaro Herrera , Dmitry Dolgov <9erthalion6@gmail.com>, Thomas Munro Subject: Re: errbacktrace In-reply-to: <35beac83-bf15-9d79-05c4-2dccd0834993@2ndquadrant.com> References: <20190708162851.GA11054@alvherre.pgsql> <3814a094-7dcd-106b-d2ad-7ef78f563356@2ndquadrant.com> <35beac83-bf15-9d79-05c4-2dccd0834993@2ndquadrant.com> Comments: In-reply-to Peter Eisentraut message dated "Tue, 13 Aug 2019 10:12:10 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <991.1565705691.1@sss.pgh.pa.us> Date: Tue, 13 Aug 2019 10:14:51 -0400 Message-ID: <992.1565705691@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Eisentraut writes: > I have changed the configuration setting to backtrace_functions plural, > so that you can debug more than one location at once. I had originally > wanted to do that but using existing functions like > SplitIdentifierString() resulted in lots of complications with error > handling (inside error handling!). So here I just hand-coded the list > splitting. Seems simple enough. I think it's a pretty bad idea for anything invocable from elog to trample on the process-wide strtok() state. Even if there's no conflict today, there will be one eventually, unless you are going to adopt the position that nobody else is allowed to use strtok(). regards, tom lane