Re: RFC: replace pg_stat_activity.waiting with something more descriptive

On Tue, Jan 19, 2016 at 11:49 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> My opinion is that storing the information in PGPROC is better because
>> it seems like we can fairly painlessly expose 4 bytes of data that way
>> instead of 1, which is nice.
>
> Okay, do you mean to say that we can place this new 4-byte variable
> in PGPROC at 4-byte aligned boundary, so both read and writes will be
> atomic?

Yes. However, note that you don't need to do anything special to get
it 4-byte aligned. The compiler will do that automatically.

>> On the topic of the UI, I understand that redefining
>> pg_stat_activity.waiting might cause some short-term annoyance. But I
>> think in the long term what we are proposing here is going to be a
>> huge improvement, so I think it's worth the compatibility break. If
>> we say that pg_stat_activity.waiting has to continue meaning "waiting
>> for a heavyweight lock" even though we now also expose (in some other
>> location) information on other kinds of waits, that's going to be
>> confusing to users.
>
> If we want to go via this route, then the first thing which we need to
> decide is whether we want to start displaying the information of
> background processes like WALWriter and others in pg_stat_activity?

That doesn't seem like a particularly good fit - few of the fields are
relevant to that case. We could provide some other way of getting at
the information for background processes if people want, but
personally I'd probably be inclined not to bother with it for right
now.

>> It's better to force people to update their
>> queries once than to have this confusing wart in the system forever.
>> I predict that if we make backward compatibility the priority here,
>> we'll still be explaining it to smart but confused people when 9.6
>> goes EOL.
>
> Valid point, OTOH we can update the docs to say that
> pg_stat_activity.waiting parameter is deprecated and after a
> release or two we can get rid of this parameter.

My impression is that doesn't really ease the pain much. Half the
time we never actually remove the deprecated column, or much later
than predicted, and people don't read the docs and keep relying on it
anyway. So in the end it just makes the process more complicated
without really helping.

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