Re: IDLE in transaction introspection

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: IDLE in transaction introspection
Дата
Msg-id CABRT9RBM3Z0-e-u9BKmFbM16TNFS2kPSKxoQhJVnhTFPAquLrA@mail.gmail.com
обсуждение исходный текст
Ответ на IDLE in transaction introspection  (Scott Mead <scottm@openscg.com>)
Ответы Re: IDLE in transaction introspection  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Список pgsql-hackers
On Mon, Oct 31, 2011 at 23:37, Scott Mead <scottm@openscg.com> wrote:
>    So I wrote the attached patch, it just turns <IDLE> in transaction into:
>  "<IDLE> in transaction\n: Previous: <last query executed>".  After seeing
> how quickly our dev's fixed the issue once they saw prepared statement XYZ,

Solving this problem is a good idea, but I don't particularly like the
proposed solution. I think the proposed state/query split is going to
make pg_stat_activity more confusing, especially if even idle
connections get a query string. And if we display the last query
there, why not the one before that? etc. (Adding a "state" column
might not be a bad idea though)

I'd very much like to see a more generic solution: a runtime query log
facility that can be queried in any way you want. pg_stat_statements
comes close, but is limited too due to its (arbitrary, I find)
deduplication -- you can't query for "10 last statements from process
N" since it has no notion of processes, just users and databases.

So far my developers are simply grepping pg_log, but you can't use the
full power of SQL there. I know there's csvlog, but the pains aren't
big enough to make attempt to use that.

Regards,
Marti


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: IDLE in transaction introspection
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: unite recovery.conf and postgresql.conf