On Tue, Aug 4, 2015 at 8:46 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 06/25/2015 07:50 AM, Tom Lane wrote:
>> To do that, we'd have to change the semantics of the 'waiting' column so
>> that it becomes true for non-heavyweight-lock waits. I'm not sure whether
>> that's a good idea or not; I'm afraid there may be client-side code that
>> expects 'waiting' to indicate that there's a corresponding row in
>> pg_locks. If we're willing to do that, then I'd be okay with
>> allowing wait_status to be defined as "last thing waited for"; but the
>> two points aren't separable.
>
> Speaking as someone who writes a lot of monitoring and alerting code,
> changing the meaning of the waiting column is OK as long as there's
> still a boolean column named "waiting" and it means "query blocked" in
> some way.
>
> Users are used to pg_stat_activity.waiting failing to join against
> pg_locks ... for one thing, there's timing issues there. So pretty much
> everything I've seen uses outer joins anyway.
All of that is exactly how I feel about it, too. It's not totally
painless to redefine waiting, but we're not proposing a *big* change
in semantics. The way I see it, if we change this now, some people
will need to adjust, but it won't really be a big deal. If we insist
that "waiting" is graven in stone, then in 5 years people will still
be wondering why the "waiting" column is inconsistent with the
"wait_state" column. That's not going to be a win.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
