Skip site navigation (1) Skip section navigation (2)

Re: Server does not start when log_statement_stats is set to on

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)CommandPrompt(dot)com>
Cc: Devrim GÜNDÜZ <devrim(at)CommandPrompt(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Server does not start when log_statement_stats is set to on
Date: 2007-12-26 18:58:13
Message-ID: 10419.1198695493@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Alvaro Herrera <alvherre(at)CommandPrompt(dot)com> writes:
> Tom Lane wrote:
>> There is some good reason, which I don't recall at the moment, why
>> assign-hooks (and most of the rest of GUC) shouldn't FATAL in the
>> middle of processing a config file.

> I'm thinking of keeping the ERROR, which (I think) would cause
> postmaster to treat it as FATAL because there is no error handler set up
> yet (no, I haven't tried it).

Yeah, it would, and that is the wrong thing.

It is definitely not acceptable to throw an ERROR unconditionally,
as that would cause postmaster abort during SIGHUP if an error is
introduced into the config file after startup.  It's possible that
we could add some state by which assign-hook routines could check
whether this is initial startup or not, but then we'd still have
the issue of whether there are any other reasons not to throw ERROR
just there (I have a feeling there are some internal-to-GUC reasons
why not, as well as the obvious one that SIGHUP shouldn't be able
to crash the postmaster).

The whole idea sounds pretty shaky to me, and definitely not
something to change in late beta.  LOG we could do now without
risking breaking anything.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2007-12-26 21:30:16
Subject: Re: Server does not start when log_statement_stats is set to on
Previous:From: Alvaro HerreraDate: 2007-12-26 18:43:07
Subject: Re: Server does not start when log_statement_stats is setto on

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group