Re: selective statement logging

Поиск
Список
Период
Сортировка
Искать
От
Andrew Dunstan
Тема
Re: selective statement logging
Дата
Msg-id
404FCECF.6030204@dunslane.net
Ответ на
Список
Дерево обсуждения
selective statement logging Andrew Dunstan <andrew@dunslane.net>
Re: selective statement logging Bruce Momjian <pgman@candle.pha.pa.us>
Re: selective statement logging Andrew Dunstan <andrew@dunslane.net>
Re: selective statement logging Bruce Momjian <pgman@candle.pha.pa.us>
Re: selective statement logging Andrew Dunstan <andrew@dunslane.net>
Re: selective statement logging Bruce Momjian <pgman@candle.pha.pa.us>
Re: selective statement logging Andrew Dunstan <andrew@dunslane.net>
Re: selective statement logging Tom Lane <tgl@sss.pgh.pa.us>
Re: selective statement logging Bruce Momjian <pgman@candle.pha.pa.us>
Re: selective statement logging Greg Stark <gsstark@mit.edu>
Re: selective statement logging Andrew Dunstan <andrew@dunslane.net>
Re: selective statement logging Andrew Dunstan <andrew@dunslane.net>
Re: selective statement logging Bruce Momjian <pgman@candle.pha.pa.us>


Andrew Dunstan wrote:

>
> Actually, I think I can improve the present situation. Currently, if 
> log_statement is not turned on and you send a query that doesn't 
> parse, all you get is the error trace. By deferring it till right 
> after the parse we can force logging of the query string on a parse 
> error, regardless of that setting (which seems to me to be a very 
> desirable outcome).  The only thing is that you will get the error 
> trace first (because it comes from the parser) rather than the query 
> string first.
>
Or I would do except that I see that a parse error causes a longjmp out 
of that code. I will see if I can come up with a way around that. If 
not, I think we'd better let sleeping dogs lie.

cheers

andrew


В списке pgsql-hackers по дате отправления
От: Tatsuo Ishii
Дата:
Сообщение: Re: [PATCHES] NO WAIT ...
От: Bruce Momjian
Дата:
Сообщение: Re: libpq thread safety
FAQ