Re: Notice lock waits
| От | Haribabu Kommi |
|---|---|
| Тема | Re: Notice lock waits |
| Дата | |
| Msg-id | CAJrrPGe=-tSbYooSsLJaQwwM9YHo88G--hAj0naMRuUSEjTAjg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Notice lock waits (Jeff Janes <jeff.janes@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Sep 30, 2016 at 3:00 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Wed, Sep 28, 2016 at 11:57 PM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:Providing the details of lock wait to the client is good. I fell this messageis useful for the cases where User/administrator is trying to perform someSQL operations.I also feel that, adding a GUC variable for these logs to show it to usermay not be good. Changing the existing GUC may be better.I don't think it would be a good idea to refactor the existing GUC (log_lock_waits) to accomplish this.There would have to be four states, log only, notice only, both log and notice, and neither. But non-superusers can't be allowed to change the log flag, only the notice flag. It is probably possible to implement that, but it seems complicated both to implement, and to explain/document. I think that adding another GUC is better than greatly complicating an existing one.
Yes, I understood. Changing the existing GUC will make it complex.
What do you think of Jim Nasby's idea of making a settable level, rather just on or off?
I am not clearly understood, how the settable level works here? Based on log_min_messages
or something, the behavior differs?
The Notification messages are good, If we are going to add this facility only for lock waits, then
a simple GUC is enough. If we are going to enhance the same for other messages, then I prefer
something like log_statement GUC to take some input from user and those messages will be
sent to the user.
Regards,
Hari Babu
Fujitsu Australia
В списке pgsql-hackers по дате отправления: