On 06/14/2011 02:20 PM, Kevin Grittner wrote:
Just on our Wiki pages we have some queries available for copy/paste
which would need multiple
versions while both column names were in supported versions of the
software:
http://wiki.postgresql.org/wiki/Lock_dependency_information
http://wiki.postgresql.org/wiki/Lock_Monitoring
http://wiki.postgresql.org/wiki/Backend_killer_function
...and most of these would actually be simplified if they could just
JOIN on pid instead of needing this common idiom:
join pg_catalog.pg_stat_activity ka
on kl.pid = ka.procpid
Yes, there are a lot of these floating around. I'd bet that in an hour
of research I could find 95% of them though, and make sure they were all
updated in advance of the release. (I already did most of this search
as part of stealing every good idea I could find in this area for my book)
I think that's consistent with the "save up our breaking changes to do them all
at
once" approach.
I don't actually buy into this whole idea at all. We already have this
big wall at 8.3 because changes made in that release are too big for
people on the earlier side to upgrade past. I'd rather see a series of
smaller changes in each release, even if they are disruptive, so that no
one version turns into a frustrating hurdle seen as impossible to
clear. This adjustment is a perfect candidate for putting into 9.2 to
me, because I'd rather reduce max(breakage) across releases than
intentionally aim at increasing it but bundling them into larger clumps.
For me, the litmus test is whether the change provides enough
improvement that it outweighs the disruption when the user runs into
it. This is why I suggested a specific, useful, and commonly requested
(to me at least) change to pg_stat_activity go along with this. If
people discover their existing pg_stat_activity tools break, presumably
they're going to look at the view again to see what changed. When they
do that, I don't want the reaction to be "why was this random change
made?" I want it to be "look, there are useful new fields in here; let
me see if I can use them too here". That's how you make people tolerate
disruption in upgrades. If they see a clear improvement in the same
spot when forced to fix around it, the experience is much more pleasant
if they get something new out of it too.
--
Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
