I wrote:
> I had a thought while looking at elog.c: we could further reduce the risk
> of quickdie() crashing if we make it do what elog.c does when it gets into
> error recursion trouble:
> error_context_stack = NULL;
> debug_query_string = NULL;
On closer inspection, ther
Andres Freund writes:
> I don't think it needs to be done right now, but I again want to suggest
> it'd be nice if we split log levels into a bitmask. If we bits, separate
> from the log level, for do-not-log-to-client and do-not-log-to-server
> some of this code would imo look nicer.
Hmm, maybe.
Hi,
On 2020-12-28 13:25:14 -0500, Tom Lane wrote:
> The most straightforward way to do that is to introduce a new error
> level. Having to renumber existing levels is a bit of a pain, but
> I'm not aware of anything that should break in source-code terms.
> We make similar ABI breaks in every maj
Andres Freund writes:
> On 2020-12-26 13:37:15 -0500, Tom Lane wrote:
>>> I'd like to not log all these repeated messages into the server
>>> log. It's quite annoying to have to digg through thousands of lines of
>>> repeated "terminating connection..."
>> Hm. That's an orthogonal issue, but cer
Hi,
On 2020-12-26 13:37:15 -0500, Tom Lane wrote:
> I suppose a compromise position could be to let the postmaster export its
> "Shutdown" state variable, and then let backends assume that SIGTERM means
> fast shutdown or pg_terminate_backend depending on the state of that one
> global variable.
Andres Freund writes:
> On 2020-12-21 16:43:33 -0500, Tom Lane wrote:
>> * I chose to report the same message for immediate shutdown as we
>> already use for SIGTERM (fast shutdown or pg_terminate_backend()).
>> Should it be different, and if so what?
[ per upthread, I did already change the SIGQ
On Sat, Dec 26, 2020 at 4:33 AM Andres Freund wrote:
> On 2020-12-21 16:43:33 -0500, Tom Lane wrote:
> > * I chose to report the same message for immediate shutdown as we
> > already use for SIGTERM (fast shutdown or pg_terminate_backend()).
> > Should it be different, and if so what?
>
> To do be
Hi,
On 2020-12-21 16:43:33 -0500, Tom Lane wrote:
> Up to now, if you shut down the database with "pg_ctl stop -m immediate"
> then clients get a scary message claiming that something has crashed,
> because backends can't tell whether the SIGQUIT they got was sent for
> a crash-and-restart situati
Bharath Rupireddy writes:
> On Tue, Dec 22, 2020 at 11:02 PM Tom Lane wrote:
>> There might be an argument for emitting the "unexpected SIGQUIT"
>> text if we find garbage in sigquit_reason. Any thoughts about that?
> Although I can't think of any case now, IMHO we can still have a
> default ca
On Tue, Dec 22, 2020 at 11:02 PM Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Dec 22, 2020 at 2:29 AM Bharath Rupireddy
> > wrote:
> >> If I'm correct, quickdie() doesn't access any shared memory because
> >> one of the reason we can be in quickdie() is when the shared memory
> >> itsel
Magnus Hagander writes:
> On Tue, Dec 22, 2020 at 2:29 AM Bharath Rupireddy
> wrote:
>> If I'm correct, quickdie() doesn't access any shared memory because
>> one of the reason we can be in quickdie() is when the shared memory
>> itself is corrupted(the comment down below on why we don't call
>>
On Tue, Dec 22, 2020 at 2:29 AM Bharath Rupireddy
wrote:
>
> On Tue, Dec 22, 2020 at 3:13 AM Tom Lane wrote:
> > Up to now, if you shut down the database with "pg_ctl stop -m immediate"
> > then clients get a scary message claiming that something has crashed,
> > because backends can't tell wheth
On Tue, Dec 22, 2020 at 3:13 AM Tom Lane wrote:
> Up to now, if you shut down the database with "pg_ctl stop -m immediate"
> then clients get a scary message claiming that something has crashed,
> because backends can't tell whether the SIGQUIT they got was sent for
> a crash-and-restart situation
Up to now, if you shut down the database with "pg_ctl stop -m immediate"
then clients get a scary message claiming that something has crashed,
because backends can't tell whether the SIGQUIT they got was sent for
a crash-and-restart situation or because of an immediate-stop command.
This isn't gre
14 matches
Mail list logo
