Обсуждение: Re: [PATCHES] WIP patch - INSERT-able log statements
On 2/19/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Guillaume Smet escribió: > > On 2/19/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > > >So add the session ID (%c) to log_line_prefix. > > > > It could work if log_line_prefix was added before every line but it's > > definitely not the case: > > myuser mydb 45d9d615.4abe LOG: duration : 185.223 ms, statement : SELECT * > > FROM lieu > > LIMIT 10; > > if you execute: > > SELECT * > > FROM lieu > > LIMIT 10; > > Interesting. I wonder why didn't you report this as a bug before? > Maybe we could have discussed it and fixed it. Perhaps because I thought it was not really a bug but the intended behaviour. Syslog has the same behaviour and it's quite logical when you consider how queries are logged (I've spent a few hours in the logging code). Syslog has exactly the same behaviour but adds the necessary context information. I'm pretty sure I have explained the problem a few times on the lists though but perhaps it was just on IRC. From the feedback I have on pgFouine, very few people think it's a real problem, probably because they don't use query logging as we do: our production servers have it enabled all the time and we have a high load on them so this particular case is a common case for us. (Second try to move this discussion to -hackers) -- Guillaume
Guillaume Smet escribió: > On 2/19/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > >Guillaume Smet escribió: > >> On 2/19/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > >> >So add the session ID (%c) to log_line_prefix. > >> > >> It could work if log_line_prefix was added before every line but it's > >> definitely not the case: > >> myuser mydb 45d9d615.4abe LOG: duration : 185.223 ms, statement : > >SELECT * > >> FROM lieu > >> LIMIT 10; > >> if you execute: > >> SELECT * > >> FROM lieu > >> LIMIT 10; > > > >Interesting. I wonder why didn't you report this as a bug before? > >Maybe we could have discussed it and fixed it. > > Perhaps because I thought it was not really a bug but the intended > behaviour. > Syslog has the same behaviour and it's quite logical when you consider > how queries are logged (I've spent a few hours in the logging code). > Syslog has exactly the same behaviour but adds the necessary context > information. If it adds necessary context then it clear does not have "the same behavior", because the problem is precisely that the context is missing. I'd propose adding a log_entry_prefix separate from log_line_prefix; the entry prefix would contain most of the stuff, and log_line_prefix would be a minimal thing intended to be put in front of each _line_, so the example you show above could be myuser mydb 45d9d615.4abe LOG: duration : 185.223 ms, statement : SELECT * 45d9d615.4abe FROM lieu 45d9d615.4abe LIMIT 10; where you have log_entry_prefix="%d %u " log_line_prefix="%c " Really, prefixing with a tab does not strike me as a great idea precisely because it's ambiguous. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 2/19/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > If it adds necessary context then it clear does not have "the same > behavior", I mean log_line_prefix behaviour is the same. The other information are syslog specific. > I'd propose adding a log_entry_prefix separate from log_line_prefix; the > entry prefix would contain most of the stuff, and log_line_prefix would > be a minimal thing intended to be put in front of each _line_, so the > example you show above could be It could be a good idea. It won't make me use stderr output but it will allow other people to do so without any disadvantage :). > Really, prefixing with a tab does not strike me as a great idea > precisely because it's ambiguous. Sure. -- Guillaume