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
