Re: procpid?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Smith <greg(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: procpid?
Date: 2011-06-15 01:50:30
Message-ID: 201106150150.p5F1oUh06496@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith wrote:
> On 06/14/2011 06:00 PM, Tom Lane wrote:
> > As far as Greg's proposal is concerned, I don't see how a proposed
> > addition of two columns would justify renaming an existing column.
> > Additions should not break any sanely-implemented application, but
> > renamings certainly will.
> >
>
> It's not so much justification as something that makes the inevitable
> complaints easier to stomach, in terms of not leaving a really bad taste
> in the user's mouth. My thinking is that if we're going to mess with
> pg_stat_activity in a way that breaks something, I'd like to see it
> completely refactored for better usability in the process. If code
> breaks and the resulting investigation by the admin highlights something
> new, that offsets some of the bad user experience resulting from the
> breakage.
>
> Also, I haven't fully worked whether it makes sense to really change
> what current_query means if the idle/transaction component of it gets
> moved to another column. Would it be better to set current_query to
> null if you are idle, rather than the way it's currently overloaded with
> text in that case? I don't like the way this view works at all, but I'm
> not sure the best way to change it. Just changing procpid wouldn't be
> the only thing on the list though.

Agreed on moving '<IDLE>' and '<IDLE> in transaction' into separate
fields. If I had thought of it I would have done it that way years ago.
(At least I think it was me.) Using angle brackets to put magic values
in that field was clearly wrong.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Creager 2011-06-15 01:50:42 Re: Why polecat and colugos are failing to build back branches
Previous Message Jaime Casanova 2011-06-15 01:24:25 Re: creating CHECK constraints as NOT VALID