Re: WIP patch - INSERT-able log statements
От | Guillaume Smet |
---|---|
Тема | Re: WIP patch - INSERT-able log statements |
Дата | |
Msg-id | 1d4e0c10702190150q531b643at38b1f025fb72f55c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP patch - INSERT-able log statements (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: WIP patch - INSERT-able log statements
|
Список | pgsql-patches |
On 2/19/07, Greg Smith <gsmith@gregsmith.com> wrote: > log_destination = 'stderr,sql' # Valid values are combinations of > # stderr, syslog, sql, and eventlog, > # depending on platform. +1 > # These are relevant when logging to sql: > log_sql_table = 'pg_log' # Table SQL formatted logs INSERT into > # Default is 'pg_log' Is there really a need for that? Why not simply put something like %log_table% in the sql file and let the admin replace it with sed or whatever he likes? And it could allow us to move to copy without having to drop the code added to manage the new GUC variable. > I personally would just ignore the duration two entries per statement > problem and make that the log analyzer software's job to fix, but I'm > likely biased here because I don't ever do anything with that data. We have basically 4 different cases: * log_min_duration_statement = 0: every query is logged with the duration on the same line, * log_statement = all: we don't have any duration, * log_statement = all & log_duration = on: we have every query and the duration on another line, * log_min_duration_statement = n > 0 & log_duration = on: we have duration lines for every query and statement + duration if the query is slower than n ms. There are other variants but I think they are the main cases to deal with. -- Guillaume
В списке pgsql-patches по дате отправления: