Bruce Momjian wrote:
>
> I am discarding this thread from the patches queue. We have fixed some
> of it so a LOG message is issued for invalid postgresql.conf
> combinations. We could do more, but there doesn't seem to be a clear
> TODO here.
Actually there's a clear TODO in GUC_complaint_elevel
I am discarding this thread from the patches queue. We have fixed some
of it so a LOG message is issued for invalid postgresql.conf
combinations. We could do more, but there doesn't seem to be a clear
TODO here.
---
Tom Lan
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I think this makes plenty of sense. However, something that occured to
> > me just now is that perhaps the right thing to do in the long term is to
> > put this message in errcontext and leave the "invalid value for XXX" as
> > the m
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think this makes plenty of sense. However, something that occured to
> me just now is that perhaps the right thing to do in the long term is to
> put this message in errcontext and leave the "invalid value for XXX" as
> the main error message. That w
Tom Lane wrote:
> That's getting to be a bit complicated to replicate in N places, though.
> Plus if we ever want to make it work like Alvaro is thinking of, we'd
> have to go back and change all those places again. So I propose
> inventing a function
>
> int guc_complaint_level(GucSource
I wrote:
> 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.
Poking around a bit more, I notice that there are already some places
that do it the way I was thinking of, eg in commands/variable.
Alvaro Herrera <[EMAIL PROTECTED]> 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
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> There are a bunch of other GUC assign hooks that behave similarly.
> >> Perhaps it'd be sensible to emit these complaints as LOG messages
> >> when we're dealing with a noninteractive source (ie, the config file)?
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There are a bunch of other GUC assign hooks that behave similarly.
>> Perhaps it'd be sensible to emit these complaints as LOG messages
>> when we're dealing with a noninteractive source (ie, the config file)?
> I was wondering whethe
Tom Lane wrote:
> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> > or can we please improve the error message here -- or is it a bug?
>
> It's not a bug. However, the specific error message only comes out in
> interactive-SET cases:
>
> if (source >= PGC_S_INTERACTIVE)
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> I'm getting this error when I set lot_statement_stats to on :
> FATAL: invalid value for parameter "log_statement_stats": 1
> Per Alexey (and Alvaro), both log_planner_stats and log_statement_stats
> cannot be turned on at the same t
Hi,
I'm getting this error when I set lot_statement_stats to on :
FATAL: invalid value for parameter "log_statement_stats": 1
and server does not start. This is "almost" default configuration file
(8.2.5, Fedora 8, running on my laptop):
http://www.gunduz.org/tmp/postgresql.conf
Per Alexey (a
12 matches
Mail list logo
