Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sun, Mar 13, 2016 at 12:40 AM, Tom Lane wrote: > In short: we've already been over this territory, at length, > and I am not excited by people trying to bikeshed it again > after the fact, especially when no new arguments are being > presented. Can we call the discussion

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

Robert Haas writes: > You could also argue that's a compatibility break, because people may > have logic that assumes that a wait is always a heavyweight lock wait. > If we keep the column but change the meaning, people who need to > update their scripts may fail to notice.

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 6:31 PM, Jim Nasby wrote: > On 3/10/16 8:36 PM, Robert Haas wrote: >> 1. We make it true only for heavyweight lock waits, and false for >> other kinds of waits. That's pretty strange. >> 2. We make it true for all kinds of waits that we now know

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 5:01 AM, Jim Nasby wrote: > > On 3/10/16 8:36 PM, Robert Haas wrote: >> >> 1. We make it true only for heavyweight lock waits, and false for >> other kinds of waits. That's pretty strange. >> 2. We make it true for all kinds of waits that we now

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 6:31 AM, Jim Nasby wrote: > On 3/10/16 8:36 PM, Robert Haas wrote: >> >> 1. We make it true only for heavyweight lock waits, and false for >> other kinds of waits. That's pretty strange. >> 2. We make it true for all kinds of waits that we now

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On 3/10/16 8:36 PM, Robert Haas wrote: 1. We make it true only for heavyweight lock waits, and false for other kinds of waits. That's pretty strange. 2. We make it true for all kinds of waits that we now know how to report. That still breaks compatibility. I would absolutely vote for 2 here.

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 23:22 GMT+01:00 Joel Jacobson : > On Sat, Mar 12, 2016 at 5:09 AM, Pavel Stehule > wrote: > >> What we need is more input on proposed changes from other companies > >> who are also heavy users of PL/pgSQL. > >> > >> Only then can we move

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 5:09 AM, Pavel Stehule wrote: >> What we need is more input on proposed changes from other companies >> who are also heavy users of PL/pgSQL. >> >> Only then can we move forward. It's like Robert is saying, there is a >> risk for bikeshedding here,

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 22:48 GMT+01:00 Joel Jacobson : > On Sat, Mar 12, 2016 at 4:41 AM, Pavel Stehule > wrote: > > I afraid so you try to look on your use case as global/generic issue. The > > PL/SQL, ADA. PL/pgSQL are verbose languages, and too shortcuts does

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 4:48 AM, Joel Jacobson wrote: > neither you nor me have nothing to add. Correction: neither you nor me have anything to add. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 4:41 AM, Pavel Stehule wrote: > I afraid so you try to look on your use case as global/generic issue. The > PL/SQL, ADA. PL/pgSQL are verbose languages, and too shortcuts does the > languages dirty. In this point we have different opinion. > > I

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 22:32 GMT+01:00 Joel Jacobson : > On Sat, Mar 12, 2016 at 4:08 AM, Robert Haas > wrote: > > > > I don't think my experience in this area is as deep as you seem to > > think. I can tell you that most of the requests EnterpriseDB gets for > >

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 22:08 GMT+01:00 Robert Haas : > On Fri, Mar 11, 2016 at 3:44 PM, Joel Jacobson wrote: > > On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas > wrote: > >> I'm not direly opposed to most of what's on that page, > >> but I'm

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sat, Mar 12, 2016 at 4:08 AM, Robert Haas wrote: > > I don't think my experience in this area is as deep as you seem to > think. I can tell you that most of the requests EnterpriseDB gets for > PL/pgsql enhancements involve wanting it to be more like Oracle's > PL/SQL,

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 3:44 PM, Joel Jacobson wrote: > On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas wrote: >> I'm not direly opposed to most of what's on that page, >> but I'm not excited about most of it, either. > > May I ask, what improvements of

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas wrote: > I'm not direly opposed to most of what's on that page, > but I'm not excited about most of it, either. May I ask, what improvements of PL/pgSQL would you personally be most excited about, if you or someone else would

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

> > Yes, I think we use this rubric quite often, and I agree it's a good one. > > > Trying to e.g. select a different number of columns into a different > > number of variables in a PL/pgSQL function doesn't throw an error. > > Bad. :( > > Yeah, I'm sympathetic to that request. That seems like

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 0:17 GMT+01:00 Tom Lane : > Robert Haas writes: > > Or ... maybe this is intentional behavior? Now that I think about it, > > doesn't each backend cache this info the first time its transaction > > reads the data? > > Your view of

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 10:49 PM, Joel Jacobson wrote: > On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas wrote: >> Well, this was discussed. If we keep the Boolean "waiting" column, then >> either: > > Oh, sorry for missing out on that discussion. > >> 1.

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 9:19 AM, Joel Jacobson wrote: > > On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas wrote: > > Well, this was discussed. If we keep the Boolean "waiting" column, then either: > > Oh, sorry for missing out on that discussion. > > > 1.

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas wrote: > Well, this was discussed. If we keep the Boolean "waiting" column, then > either: Oh, sorry for missing out on that discussion. > 1. We make it true only for heavyweight lock waits, and false for > other kinds of

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 8:31 PM, Joel Jacobson wrote: > This is an excellent feature, thanks! > But can we please keep the old boolean waiting column? > I see no reason to break backward-compatibility. Or maybe I'm missing > something. Well, this was discussed. If we keep the

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

This is an excellent feature, thanks! But can we please keep the old boolean waiting column? I see no reason to break backward-compatibility. Or maybe I'm missing something. I just had to commit this to make our system run locally on 9.6: commit 2e189f85fa56724bec5c5cab2fcf0d2f3a4ce22a Author:

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

Robert Haas writes: > Or ... maybe this is intentional behavior? Now that I think about it, > doesn't each backend cache this info the first time its transaction > reads the data? Your view of pg_stat_activity is supposed to hold still within a transaction, yes.

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 5:07 PM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 5:05 PM, Robert Haas wrote: >> On Thu, Mar 10, 2016 at 4:51 PM, Pavel Stehule >> wrote: >>> Maybe it be clear from attached text file >> >> Uh,

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 5:05 PM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 4:51 PM, Pavel Stehule > wrote: >> Maybe it be clear from attached text file > > Uh, yikes, that looks messed up, but I wouldn't have thought this > commit would have

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 4:51 PM, Pavel Stehule wrote: > Maybe it be clear from attached text file Uh, yikes, that looks messed up, but I wouldn't have thought this commit would have changed anything there one way or the other. The current query is reported by

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-10 22:24 GMT+01:00 Robert Haas : > > rhaas=# select query, state, wait_event, wait_event_type from > pg_stat_activity; > query > | state | wait_event | wait_event_type > >

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 3:44 PM, Pavel Stehule wrote: > I am trying to test this feature, and there I see not actual data. Maybe > this behave is not related to this patch: > > create table foo(a int); > insert into foo values(10); > > session one: > > begin; select *