Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Joel Jacobson <joel(at)trustly(dot)com>, 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:40:36
Message-ID: 29328.1457804436@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2016-03-12 19:46:25 Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat
Previous Message Robert Haas 2016-03-12 17:19:30 Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-03-12 18:53:06 Re: pl/pgSQL, get diagnostics and big data
Previous Message Vladimir Borodin 2016-03-12 17:40:06 Re: Background Processes and reporting