Re: log_statement and PREPARE
От
brian
Тема
Re: log_statement and PREPARE
Дата
Msg-id
46E0B878.1040000@zijn-digital.com
Ответ на
Re: log_statement and PREPARE (Tom Lane)
Список
Дерево обсуждения
log_statement and PREPARE brian <brian@zijn-digital.com>
Re: log_statement and PREPARE Tom Lane <tgl@sss.pgh.pa.us>
Re: log_statement and PREPARE brian <brian@zijn-digital.com>
Re: log_statement and PREPARE Tom Lane <tgl@sss.pgh.pa.us>
Re: log_statement and PREPARE brian <brian@zijn-digital.com>
Re: log_statement and PREPARE Tom Lane <tgl@sss.pgh.pa.us>
Re: log_statement and PREPARE brian <brian@zijn-digital.com>
Re: log_statement and PREPARE Tom Lane <tgl@sss.pgh.pa.us>
Re: log_statement and PREPARE brian <brian@zijn-digital.com>
Tom Lane wrote: > brian writes: > >>The only hint of a prepared statement being logged is when there's an >>error. eg: > > >><2007-09-05 17:35:22 EDT>ERROR: duplicate key violates unique >>constraint "auth_member_id_key" >><2007-09-05 17:35:22 EDT>STATEMENT: EXECUTE >>mdb2_statement_pgsqla0e8d35156e904f9581ac790eb917b98 (A_HASH_HERE, 5271) > > > That looks like an EXECUTE to me. If you want EXECUTEs to be logged > conditionally based on what they are executing, you need 8.2. > That was understood. What i meant is that the only time i see anything *related to* the prepared statement i think should be there is when the EXECUTE fails for some reason because the context of the error is logged. That particular EXECUTE was preceeded by a PREPARE that was not logged. It was my understanding that the PREPARE would be logged. In any case, i'll upgrade soonest. I keep reading here about all the 8.2 goodness. brian
В списке pgsql-general по дате отправления