Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.
Date
Msg-id 29328.1457804436@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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.

Yes.  My recollection of the argument for the earlier renames of
pg_stat_activity columns is that it was basically the same thing:
we changed the semantics of these columns, you are very likely to
need to adjust your queries, so we'll change the column names to
make sure you notice.  There's always a tradeoff there.  Maybe you
won't need to adjust your queries, but maybe they'll break silently.

In this case I agree with the feeling that people probably took
waiting == true as an indication that there was a matching entry
in pg_locks, so the odds of subtle breakage if we keep the name
the same while changing the semantics are pretty high.  Or we
could keep the semantics the same (waiting is true only for
heavyweight-lock waits) but that was mighty ugly too.

In short: we've already been over this territory, at length,
and I am not excited by people trying to bikeshed it again
after the fact, especially when no new arguments are being
presented.  Can we call the discussion closed, please?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Vladimir Borodin
Date:
Subject: Re: Background Processes and reporting
Next
From: Tom Lane
Date:
Subject: Re: pl/pgSQL, get diagnostics and big data