On Fri, Sep 30, 2016 at 3:00 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Wed, Sep 28, 2016 at 11:57 PM, Haribabu Kommi <kommi.harib...@gmail.com > > wrote: >> >> >> Providing the details of lock wait to the client is good. I fell this >> message >> is useful for the cases where User/administrator is trying to perform some >> SQL operations. >> >> I also feel that, adding a GUC variable for these logs to show it to user >> may 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
