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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Joel Jacobson <joel(at)trustly(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.
Date: 2016-03-12 17:19:30
Message-ID: CA+TgmoYuzzhvimO-32eo3OR7PX1_3T0YjM_jBug1qqm7po1O8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Fri, Mar 11, 2016 at 6:31 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> 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 how to
>> report. That still breaks compatibility.
>
>
> I would absolutely vote for 2 here. You could even argue that it's a bug
> fix, since those were waits we technically should have been indicating.

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. Hard breaks aren't that fun,
but at least you don't fail to notice that something needs to be
changed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-03-12 17:40:36 Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.
Previous Message Tom Lane 2016-03-12 17:13:07 pgsql: Re-export a few of createplan.c's make_xxx() functions.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-12 17:21:57 Re: eXtensible Transaction Manager API (v2)
Previous Message Robert Haas 2016-03-12 17:16:50 Re: Performance improvement for joins where outer side is unique