Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.
От | Amit Kapila |
---|---|
Тема | Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity. |
Дата | |
Msg-id | CAA4eK1+gaV3D=Y+ecHgAm42o7LbcqfwtNMKeD5xDYm7G2bpjKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity. (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Список | pgsql-hackers |
On Sat, Mar 12, 2016 at 5:01 AM, Jim Nasby <Jim.Nasby@bluetreble.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.
>
I see it as reverse. I think waiting=true for only heavyweight locks makes sense in existing versions as user can still find whats actually going in the system either by looking at "query" in pg_stat_activity or by referring pg_locks, but OTOH if waiting is true for all kind of waits (lwlock, heavyweight lock, I/O, etc) then I think it will be difficult for user to make any sense out of it. So I see going for option 2 can confuse users rather than simplifying anything.
>
> Another random thought... changes like this would probably be easier to handle if we provided backwards compatibility extensions that created views > that mimicked the catalog for a specific Postgres version.
>
>
> 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.
>
I see it as reverse. I think waiting=true for only heavyweight locks makes sense in existing versions as user can still find whats actually going in the system either by looking at "query" in pg_stat_activity or by referring pg_locks, but OTOH if waiting is true for all kind of waits (lwlock, heavyweight lock, I/O, etc) then I think it will be difficult for user to make any sense out of it. So I see going for option 2 can confuse users rather than simplifying anything.
>
> Another random thought... changes like this would probably be easier to handle if we provided backwards compatibility extensions that created views > that mimicked the catalog for a specific Postgres version.
>
That makes sense to me if other people agree to it, but I think there will be some maintenance overhead for it, but I see that as worth the effort in terms of user convenience.
В списке pgsql-hackers по дате отправления: