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

On Thu, Mar 10, 2016 at 10:49 PM, Joel Jacobson <joel@trustly.com> wrote:
> On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Well, this was discussed.  If we keep the Boolean "waiting" column, then either:
>
> Oh, sorry for missing out on that discussion.
>
>> 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.
>
> Why not 3: We make it true for exactly the same type of situations as
> in previous versions. Or is it not possible to do so for some reason?

3 = 1.

> Off topic, but related to the backward-compatibility subject:
>
> Is there any written policy/wiki/thread/document on the topic "When
> breaking backward-compatibility is acceptable"?

Not to my knowledge.  We end up hashing it out on a case-by-case basis.

> It would be helpful to get a better understand of this, as some ideas
> on how to improve things can quickly be ruled out or ruled in
> depending on what is acceptable or not.
> For instance, there are some minor but annoying flaws in PL/pgSQL that
> I would love to get fixed,
> but the main arguments against doing so have been that it might break
> some users' code somewhere,
> even though doing so would probably be a good thing as the user could
> have a bug in the code.
> See: https://wiki.postgresql.org/wiki/Improving_PL/PgSQL_(September_2014)

I think that with respect to this particular set of improvements, the
problem is basically that there are just a lot of things that you
could hypothetically change, and it's not altogether clear which ones
of those individually would please more people than they displeased,
and it's not clear how much change we want to allow in total for the
sake of preserving backward compatibility, and then, too, the designs
for a lot of the individual features are fertile ground for
bikeshedding.  I'm not direly opposed to most of what's on that page,
but I'm not excited about most of it, either.  I bet if we canvassed
10 different companies that made heavy use of PL/pgsql they'd all have
a list of proposed changes like that, and I bet some of them would
conflict with each other, and I bet if we did all that stuff the
average PL/pgsql user's life would not be much better, but the manual
would be much longer.

(Also, I bet the variable assignments thing would break large amounts
of code that is working as designed.)

> I think one general rule should be "Breaking backward-compatibility is
> acceptable if the new major pg-version throws an error in a situation
> where the old major pg-version would conceal a bug or allow misuse of
> a feature".
> Trying to select the now removed "waiting" column throws an error.
> Good! That lead me as a user here to figure out why I can't and
> shouldn't use it. :)

Yes, I think we use this rubric quite often, and I agree it's a good one.

> Trying to e.g. select a different number of columns into a different
> number of variables in a PL/pgSQL function doesn't throw an error.
> Bad. :(

Yeah, I'm sympathetic to that request.  That seems like poor error
checking and nothing else.

(But note that I do not rule here.)

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