From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: I am done |
Date: | 2002-09-03 01:54:35 |
Message-ID: | Pine.LNX.4.21.0209031135520.30699-100000@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2 Sep 2002, Bruce Momjian wrote:
> > >> Oh, didn't you put in that patch to provide a GUC level control?
> >
> > > Yes, but what level do you set it at to turn it off?
> >
> > FATAL? PANIC?
>
> He doesn't support those levels:
>
> test=> set log_min_error_statement = fatal;
> ERROR: invalid value for option 'log_min_error_statement': 'fatal'
> test=> set log_min_error_statement = error;
> SET
>
> and in fact, the default is ERROR. I think the default has to be
> something higher, but even FATAL seems wrong. We have to be able to
> turn it off, and have it off by default, rather than saying it only
> happens with fatal errors or something like that.
Okay, my bad. From my reading of the email exchange, I thought people
wanted this on -- always. The best solution for this, in my opinion, is to
have a magic value "off" which the error code lookup translates to some
number > PANIC.
Secondly, there is a flaw in the patch. I merged all the
assign_server_min_messages() and assign_client_min_messages() code to make
things pretty. Perhaps I shouldn't have (since I left off FATAL and PANIC
from the list, which I shouldn't have for the prior but should have for
the latter). So there are a few ways to fix it: allow both functions (+
the log_min_error_state function) to accept all possible error codes +
"off" (which does nothing for the first two functions); pass a unique
number for each function to assign_msglvl() so that we can determine the
a legal error code for that GUC variable is being assigned; or, just have
different lists.
Now, the first solution is a hack, but it shouldn't actually break
anything. The second is overkill. The third is the best way to do it but
as we add more of these kinds of functions (log_min_parse,
log_min_rewritten? -- I can a use for that) the amount of assign_ code
will grow linearly and be pretty similar.
Ideas?
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-09-03 02:10:02 | Re: I am done |
Previous Message | Tom Lane | 2002-09-03 01:54:00 | 7.3 gotchas for applications and client libraries |