Re: IDLE in transaction introspection - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: IDLE in transaction introspection
Date
Msg-id CABUevExTdxP58X86rdbeAiNf=4RGTfVeKZGDAK62DvyjWavc4g@mail.gmail.com
Whole thread Raw
In response to Re: IDLE in transaction introspection  (Scott Mead <scottm@openscg.com>)
Responses Re: IDLE in transaction introspection  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Wed, Jan 18, 2012 at 16:35, Scott Mead <scottm@openscg.com> wrote:
>
> On Wed, Jan 18, 2012 at 8:27 AM, Magnus Hagander <magnus@hagander.net>
> wrote:
>>
>> On Tue, Jan 17, 2012 at 01:43, Scott Mead <scottm@openscg.com> wrote:
>> >
>> >
>> > On Mon, Jan 16, 2012 at 6:10 PM, Scott Mead <scottm@openscg.com> wrote:
>> >>
>> >>
>> >> On Sun, Jan 15, 2012 at 4:28 AM, Greg Smith <greg@2ndquadrant.com>
>> >> wrote:
>> >>>
>> >>> On 01/12/2012 11:57 AM, Scott Mead wrote:
>> >>>>
>> >>>> Pretty delayed, but please find the attached patch that addresses all
>> >>>> the issues discussed.
>> >>>
>> >>>
>> >>> The docs on this v4 look like they suffered a patch order problem
>> >>> here.
>> >>>  In the v3, you added a whole table describing the pg_stat_activity
>> >>> documentation in more detail than before.  v4 actually tries to remove
>> >>> those
>> >>> new docs, a change which won't even apply as they don't exist
>> >>> upstream.
>> >>>
>> >>> My guess is you committed v3 to somewhere, applied the code changes
>> >>> for
>> >>> v4, but not the documentation ones.  It's easy to do that and end up
>> >>> with a
>> >>> patch that removes a bunch of docs the previous patch added.  I have
>> >>> to be
>> >>> careful to always do something like "git diff origin/master" to avoid
>> >>> this
>> >>> class of problem, until I got into that habit I did this sort of thing
>> >>> regularly.
>> >>>
>> >> gak
>> >
>> >
>> > I did a 'backwards' diff last time.  This time around, I diff-ed off of
>> > a
>> > fresh pull of 'master' (and I did the diff in the right direction.
>> >
>> > Also includes whitespace cleanup and the pg_stat_replication (procpid
>> > ==>
>> > pid) regression fix.
>> >
>>
>> I'm reviewing this again, and have changed a few things around. I came
>> up with a question, too :-)
>>
>> Right now, if you turn off track activities, we put "<command string
>> not enabled>" in the query text. Shouldn't this also be a state, such
>> as "disabled"? It seems more consistent to me...
>
>
> Sure, I was going the route of 'client_addr', i.e. leaving it null when not
> in use just to keep screen clutter down, but I'm not married to it.

Applied with fairly extensive modifications. I moved things around,
switched to using enum instead of int+#define and a few things like
that. Also changed most of the markup in the docs - I may well have
broken some previously good language that, so if I did and someone
spots it, please mention it :-)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: review:tracking temporary files in pg_stat_database
Next
From: Alvaro Herrera
Date:
Subject: Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter