Re: I am done

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

In response to

Responses

Browse pgsql-hackers by date

  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