Re: SELECT .. FOR UPDATE: find out who locked a row - Mailing list pgsql-general

From Melvin Davidson
Subject Re: SELECT .. FOR UPDATE: find out who locked a row
Date
Msg-id CANu8FiyTAPu5TVtL1g2eSocn-axAsJm+o4Hb9qz0a6JK+=WPAQ@mail.gmail.com
Whole thread Raw
In response to Re: SELECT .. FOR UPDATE: find out who locked a row  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SELECT .. FOR UPDATE: find out who locked a row  (Stephen Frost <sfrost@snowman.net>)
List pgsql-general
Tom,
this whole discussion started because Enrico did not originally specify the PostgreSQL version he was working with. So after he did advise it was for 9.6, I felt it necessary to explain to him why a certain section of my query was commented out and that it would also work for 10. I have previously made it a policy to request ops include the PostgreSQL version and O/S when submitting to this list, but I was berated by others for always requesting ops to provide that extremely difficult information to obtain.
I also felt it important that I express my opinion that the changes needed were caused by what I felt was cosmetic and unnecessary changes to the catalog. There is an old saying "If it ain't broke, don't fix it" and that certainly applies here.

Now, as to your request for me to read the thread in the url's you suggested, I did read most of the content. I note that the entire discussion was amongst
PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, So at no time was the generic population of PostgreSQL users and DBA's involved. Therefore, said population, myself included, had no foreknowledge of the intended changes which is the cause of the problem. Therefore your statement "you might want to consider speaking up in some reasonable time frame, not six years later" is abrasive at best, since I, and others, only found out about it after the fact. Not to mention, even if I did complain earlier, I seriously doubt the changes could or would be reversed.

At this point I have said all I have to say and will discuss it no further. I can only strongly recommend that in the future, proposed changes to system catalogs that could adversely affect existing scripts and applications be sent to the generic PostgreSQL population (IE: pgsql-general@lists.postgresql.org) for comment BEFORE said changes are implemented.

On Thu, Mar 15, 2018 at 11:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Melvin Davidson <melvin6925@gmail.com> writes:
> Yes, Stephen, I certainly understand making changes to system catalogs
> _when necessary_.  That being said, the first change was the renaming of
> pid to procpid in pg_stat_activity.  However, I contend that was more
> because someone felt that it was more to make the column names
> consistent across catalogs, rather than necessity.

Please read all of
https://www.postgresql.org/message-id/flat/201106091554.p59Fso314146%40momjian.us
where this was discussed to death (and rejected), and then read all of
https://www.postgresql.org/message-id/flat/CAKq0gvK8PzMWPv19_o7CGg8ZQ0G%2BUuAWor5RrAg0SOmWTqqLwg%40mail.gmail.com
which is the thread in which the change was agreed to after all
(on the grounds that we were breaking backwards compatibility of
the view anyway with respect to other, more important, columns).

If you still feel that we make incompatible changes without adequate
consideration, that's your right, but you might want to consider
speaking up in some reasonable time frame, not six years later.
This could have been objected to as late as 9.2 beta, so it's not
like you need to be drinking from the pgsql-hackers firehose continually
in order to weigh in.  But 9.2 is not just released, it's EOL, so it's
really kinda late to be objecting.

                        regards, tom lane



--
Melvin Davidson
Maj. Database & Exploration Specialist

Universe Exploration Command – UXC

Employment by invitation only!

pgsql-general by date:

Previous
From: "Martin Moore"
Date:
Subject: RE: Circle and box intersect
Next
From: Alexander Farber
Date:
Subject: STRING_AGG and GROUP BY