Notice lock waits

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Notice lock waits
Дата
Msg-id CAMkU=1xGV=xEOYFeDmRxRXc1okzyGa+=J_7Brgi--MQO3Ej8XQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: Notice lock waits  (Julien Rouhaud <julien.rouhaud@dalibo.com>)
Re: Notice lock waits  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Notice lock waits  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Notice lock waits  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Re: Notice lock waits  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список pgsql-hackers
One time too many, I ran some minor change using psql on a production
server and was wondering why it was taking so much longer than it did
on the test server.  Only to discover, after messing around with
opening new windows and running queries against pg_stat_activity and
pg_locks and so on, that it was waiting for a lock.

So I created a new guc, notice_lock_waits, which acts like
log_lock_waits but sends the message as NOTICE so it will show up on
interactive connections like psql.

I turn it on in my .psqlrc, as it doesn't make much sense for me to
turn it on in non-interactive sessions.

A general facility for promoting selected LOG messages to NOTICE would
be nice, but I don't know how to design or implement that.  This is
much easier, and I find it quite useful.

I have it PGC_SUSET because it does send some tiny amount of
information about the blocking process (the PID) to the blocked
process.  That is probably too paranoid, because the PID can be seen
by anyone in the pg_locks table anyway.

Do you think this is useful and generally implemented in the correct
way?  If so, I'll try to write some sgml documentation for it.

Cheers,

Jeff

Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Logical Replication WIP