Thread: Re: [HACKERS] logging statement levels
Bruce Momjian wrote: >Andrew Dunstan wrote: > > >>Bruce Momjian wrote: >> >> >> >>>Andrew Dunstan wrote: >>> >>> >>> >>> >>>>Unless I'm missing something, this patch has the effect that with values >>>>of "ddl" or "mod" for log_statement, a statement with a parse error >>>>will not be logged, which was what I hoped to avoid. >>>> >>>> >>>> >>>> >>>Right. The query type can't be determined during a syntax error because >>>the parser couldn't identify the supplied command. I think that is >>>fine. >>> >>>What it does allow is to for 'all' to display the command before the >>>syntax error. >>> >>> >>> >>> >>> >>If I had to make a choice I'd go the other way. >> >> > >Uh, what other way? > > reverse the order rather than suppress the message. > > >>However, I think with a little extra work it might be possible to have both. >> >> > >Right now, the way it is done, only a real syntax error skips logging. >If you referenced an invalid table or something, it does print the log >just before the invalid table name mention. > >How would we test the command type before hitting a syntax error? I >can't think of a way, and I am not sure it would even be meaningful. > > > I agree that you can't test the statement type on a parse error. But that doesn't mean to me that "mod" should suppress logging statements with syntax errors. In fact, after the discussion surrounding this I thought the consensus was to have these things as additive rather than just one level selected. How to do it in the order you prefer? I would trap the parse error and log the statement before emitting the error log. If I find a simple way I'll submit a further patch. Certainly your patch contains the guts of what needs to be done in any case. cheers andrew cheers andrew
Andrew Dunstan wrote:
> >>However, I think with a little extra work it might be possible to have both.
> >>
> >>
> >
> >Right now, the way it is done, only a real syntax error skips logging.
> >If you referenced an invalid table or something, it does print the log
> >just before the invalid table name mention.
> >
> >How would we test the command type before hitting a syntax error? I
> >can't think of a way, and I am not sure it would even be meaningful.
> >
> >
> >
>
> I agree that you can't test the statement type on a parse error. But
> that doesn't mean to me that "mod" should suppress logging statements
> with syntax errors. In fact, after the discussion surrounding this I
> thought the consensus was to have these things as additive rather than
> just one level selected.
It is additive in that 'mod' also includes 'ddl' queries.
> How to do it in the order you prefer? I would trap the parse error and
> log the statement before emitting the error log.
>
> If I find a simple way I'll submit a further patch.
>
> Certainly your patch contains the guts of what needs to be done in any case.
Right now we have log_min_error_statement:
#log_min_error_statement = panic # Values in order of increasing severity:
# debug5, debug4, debug3, debug2, debug1,
# info, notice, warning, error, panic(off)
which does allow control of printing only statements generating errors,
which includes syntax errors. I don't see why this functionality should
be mixed in with log_statement.
Did you want a 'syntax error' level to log_statement, that would print
only statements with syntax errors but not other errors? That doesn't
seem very useful to me.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: >Right now we have log_min_error_statement: > > #log_min_error_statement = panic # Values in order of increasing severity: > # debug5, debug4, debug3, debug2, debug1, > # info, notice, warning, error, panic(off) > >which does allow control of printing only statements generating errors, >which includes syntax errors. I don't see why this functionality should >be mixed in with log_statement. > >Did you want a 'syntax error' level to log_statement, that would print >only statements with syntax errors but not other errors? That doesn't >seem very useful to me. > > > It wasn't my idea, but I thought it was a good one. But it would go along with the idea of these settings as a list instead of a hierarchy, e.g.: log_statement = "syntax-errors, ddl, mod" In fact, I liked it so much that I thought "syntax-errors" should be the default instead of "none". I think I'd prefer that to having it tied to the log_min_error_statement level. But I don't care that much. cheers andrew
Andrew Dunstan wrote: > Bruce Momjian wrote: > > >Right now we have log_min_error_statement: > > > > #log_min_error_statement = panic # Values in order of increasing severity: > > # debug5, debug4, debug3, debug2, debug1, > > # info, notice, warning, error, panic(off) > > > >which does allow control of printing only statements generating errors, > >which includes syntax errors. I don't see why this functionality should > >be mixed in with log_statement. > > > >Did you want a 'syntax error' level to log_statement, that would print > >only statements with syntax errors but not other errors? That doesn't > >seem very useful to me. > > > > > > > > It wasn't my idea, but I thought it was a good one. But it would go > along with the idea of these settings as a list instead of a hierarchy, > e.g.: > > log_statement = "syntax-errors, ddl, mod" > > In fact, I liked it so much that I thought "syntax-errors" should be the > default instead of "none". > > I think I'd prefer that to having it tied to the log_min_error_statement > level. But I don't care that much. OK, at least we understand each other. Right now we don't have any special "syntax error" log processing. We have errors logged through log_min_error_statement, and mod/ddl through the new log_statement. I can see a use case for having mod/ddl control of logging, and error control of logging, but why would you want to see syntax error queries but not other error queries? That's why I think log_min_error_statement is sufficient. If we add syntax logging, wouldn't that conflict with log_min_error_statement logging, because those are errors too. Maybe we need to add a 'synax' mode to log_min_error_statement above error that logs only syntax errors but not others. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: >Andrew Dunstan wrote: > > >>Bruce Momjian wrote: >> >> >> >>>Right now we have log_min_error_statement: >>> >>> #log_min_error_statement = panic # Values in order of increasing severity: >>> # debug5, debug4, debug3, debug2, debug1, >>> # info, notice, warning, error, panic(off) >>> >>>which does allow control of printing only statements generating errors, >>>which includes syntax errors. I don't see why this functionality should >>>be mixed in with log_statement. >>> >>>Did you want a 'syntax error' level to log_statement, that would print >>>only statements with syntax errors but not other errors? That doesn't >>>seem very useful to me. >>> >>> >>> >>> >>> >>It wasn't my idea, but I thought it was a good one. But it would go >>along with the idea of these settings as a list instead of a hierarchy, >>e.g.: >> >>log_statement = "syntax-errors, ddl, mod" >> >>In fact, I liked it so much that I thought "syntax-errors" should be the >>default instead of "none". >> >>I think I'd prefer that to having it tied to the log_min_error_statement >>level. But I don't care that much. >> >> > >OK, at least we understand each other. Right now we don't have any >special "syntax error" log processing. We have errors logged through >log_min_error_statement, and mod/ddl through the new log_statement. > >I can see a use case for having mod/ddl control of logging, and error >control of logging, but why would you want to see syntax error queries >but not other error queries? That's why I think log_min_error_statement >is sufficient. If we add syntax logging,Thinks wouldn't that conflict with >log_min_error_statement logging, because those are errors too. Maybe we >need to add a 'synax' mode to log_min_error_statement above error that >logs only syntax errors but not others. > > > Thinks .... experiments .... yes, OK, I agree. Please forgive any denseness. Not sure if we need another level. Why do we have log_min_error_statement default to PANIC level? Wouldn't ERROR be a better default? cheers andrew
Andrew Dunstan wrote: > >>I think I'd prefer that to having it tied to the log_min_error_statement > >>level. But I don't care that much. > >> > >> > > > >OK, at least we understand each other. Right now we don't have any > >special "syntax error" log processing. We have errors logged through > >log_min_error_statement, and mod/ddl through the new log_statement. > > > >I can see a use case for having mod/ddl control of logging, and error > >control of logging, but why would you want to see syntax error queries > >but not other error queries? That's why I think log_min_error_statement > >is sufficient. If we add syntax logging,Thinks wouldn't that conflict with > >log_min_error_statement logging, because those are errors too. Maybe we > >need to add a 'synax' mode to log_min_error_statement above error that > >logs only syntax errors but not others. > > > > > > > > Thinks .... experiments .... yes, OK, I agree. Please forgive any > denseness. Not sure if we need another level. No problem. It is good to think through these things to make sure we have everything covered. > Why do we have log_min_error_statement default to PANIC level? Wouldn't > ERROR be a better default? Panic basically means off, meaning we don't print queries that generate errors. Should we print them by default? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073