From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Printing backtrace of postgres processes
Date: Tue, 19 Jan 2021 12:50:55 -0500
Message-ID: <492025.1611078655@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmobpOhhm0poFsShjoM=sOxkbzc78f2TdNyZpGz4GSJHh6g@mail.gmail.com>
References: <CALDaNm3ZzmFS-=r7oDUzj7y7BgQv+N06Kqyft6C3xZDoKnk_6w@mail.gmail.com>
<1778088.1606026308@sss.pgh.pa.us>
<20201201032649.aekv5b5dicvmovf4@alap3.anarazel.de>
<1361750.1606795285@sss.pgh.pa.us>
<CALDaNm0pUzawA96LjKohn8eF2BSxkZMRvO70M1-bcbhGvznQuA@mail.gmail.com>
<CALDaNm0DN3TJsSP6PT=maw1KLKvhHwFfOhokUGKprLaiZrU-mw@mail.gmail.com>
<55526d79-247d-83a1-0961-7d42e0db1870@enterprisedb.com>
<20210115201011.noomcygirzge43ir@alap3.anarazel.de>
<CALDaNm2wjFrizmy+yvNbedYKxorZBcGYXNMaoPC6zwSaLsmwLg@mail.gmail.com>
<3537.1610828491@sss.pgh.pa.us>
<CA+TgmobpOhhm0poFsShjoM=sOxkbzc78f2TdNyZpGz4GSJHh6g@mail.gmail.com>
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jan 16, 2021 at 3:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (Personally, I think this whole patch fails the safety-vs-usefulness
>> tradeoff, but I expect I'll get shouted down.)
> What do you see as the main safety risks here?
The thing that is scaring me the most is the "broadcast" aspect.
For starters, I think that that is going to be useless in the
field because of the likelihood that different backends' stack
traces will get interleaved in whatever log file the traces are
going to. Also, having hundreds of processes spitting dozens of
lines to the same place at the same time is going to expose any
little weaknesses in your logging arrangements, such as rsyslog's
tendency to drop messages under load.
I think it's got security hazards as well. If we restricted the
feature to cause a trace of only one process at a time, and required
that process to be logged in as the same database user as the
requestor (or at least someone with the privs of that user, such
as a superuser), that'd be less of an issue.
Beyond that, well, maybe it's all right. In theory anyplace that
there's a CHECK_FOR_INTERRUPTS should be okay to call elog from;
but it's completely untested whether we can do that and then
continue, as opposed to aborting the transaction or whole session.
I share your estimate that there'll be small-fraction-of-a-percent
hazards that could still add up to dangerous instability if people
go wild with this.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, vignesh21@gmail.com, andres@anarazel.de, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Printing backtrace of postgres processes
In-Reply-To: <492025.1611078655@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox