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
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. |
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 |