Re: [HACKERS] Notice lock waits

2016-10-02 Thread Michael Paquier
On Mon, Oct 3, 2016 at 11:40 AM, Michael Paquier wrote: > On Fri, Sep 30, 2016 at 2:00 AM, Jeff Janes wrote: >> What do you think of Jim Nasby's idea of making a settable level, rather >> just on or off? > > [reading the code] > That would be a

Re: [HACKERS] Notice lock waits

2016-10-02 Thread Michael Paquier
On Fri, Sep 30, 2016 at 2:00 AM, Jeff Janes wrote: > What do you think of Jim Nasby's idea of making a settable level, rather > just on or off? [reading the code] That would be a better idea. The interface proposed, aka 2 GUCs doing basically the same thing is quite

Re: [HACKERS] Notice lock waits

2016-09-29 Thread Haribabu Kommi
On Fri, Sep 30, 2016 at 3:00 AM, Jeff Janes wrote: > On Wed, Sep 28, 2016 at 11:57 PM, Haribabu Kommi > wrote: >> >> >> Providing the details of lock wait to the client is good. I fell this >> message >> is useful for the cases where

Re: [HACKERS] Notice lock waits

2016-09-29 Thread Jeff Janes
On Wed, Sep 28, 2016 at 11:57 PM, Haribabu Kommi wrote: > > > On Sat, Aug 6, 2016 at 3:00 AM, Jeff Janes wrote: > >> 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

Re: [HACKERS] Notice lock waits

2016-09-29 Thread Haribabu Kommi
On Sat, Aug 6, 2016 at 3:00 AM, Jeff Janes wrote: > 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

Re: [HACKERS] Notice lock waits

2016-09-06 Thread Pavan Deolasee
On Fri, Aug 5, 2016 at 10:30 PM, Jeff Janes wrote: > > > 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. > > IMHO that's what we need and

Re: [HACKERS] Notice lock waits

2016-08-31 Thread Jeff Janes
On Tue, Aug 9, 2016 at 5:17 PM, Jim Nasby wrote: > On 8/5/16 12:00 PM, Jeff Janes wrote: > >> 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. >> > >

Re: [HACKERS] Notice lock waits

2016-08-09 Thread Jim Nasby
On 8/5/16 12:00 PM, Jeff Janes wrote: 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 would strongly prefer that this accept a log level instead of being hard-coded to NOTICE.

Re: [HACKERS] Notice lock waits

2016-08-05 Thread Jeff Janes
On Fri, Aug 5, 2016 at 12:17 PM, Tom Lane wrote: > Jeff Janes writes: >> 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

Re: [HACKERS] Notice lock waits

2016-08-05 Thread Tom Lane
Jeff Janes writes: > 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. Why not just

Re: [HACKERS] Notice lock waits

2016-08-05 Thread Julien Rouhaud
On 05/08/2016 19:00, Jeff Janes wrote: > 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

[HACKERS] Notice lock waits

2016-08-05 Thread Jeff Janes
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