Re: procpid?

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    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us