Re: implement query_start for pg_stat_activity - Mailing list pgsql-patches

From Rod Taylor
Subject Re: implement query_start for pg_stat_activity
Date
Msg-id 1045973753.84130.81.camel@jester
Whole thread Raw
In response to Re: implement query_start for pg_stat_activity  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
On Wed, 2003-02-19 at 01:45, Neil Conway wrote:
> On Wed, 2003-02-19 at 01:04, Tom Lane wrote:
> > NAMEDATALEN=32 will have been history for two releases when this gets
> > out.  I don't agree with artificially constricting a function name to
> > conform to an obsolete restriction --- and for *sure* I don't agree with
> > renaming an existing function to make it line up with a new, artificial
> > name ...
>
> Fair enough.
>
> > > (2) I wasn't sure how to convert a struct timeval into a PostgreSQL
> > > timestamp type, so I hacked something together involving ctime() and
> > > timestamp_in(), but it seems clearly wrong.
> >
> > GetCurrentAbsoluteTimeUsec() followed by now() seem to do it at the
> > moment ...
>
> Can you elaborate a bit? Since now() returns the time the current txn
> started, that doesn't seem to be what I'd need -- and isn't
> GetCurrentAbsoluteTimeUsec() essentially just an (ugly) wrapper over
> gettimeofday()?
>
> I think a similar function to timeofday() that returns a timestamp would
> probably be ideal... (which reminds me, we should probably think about
> how to replace timeofday() with something that doesn't return a string).
>
> > Care to offer a proposal for simplifying this code?
>
> To be honest, I wouldn't know where to start -- I don't really know much
> about the intricacies of datetime manipulation...


I did a quick patch a while ago that would simply use Abstime -- setting
query_start and connection_start (when the backend was fired up).

Another thing it did was to change pg_stat_activity into a single SRF
removing a good chunk of the other junk.

Anyway, after using it for a while on a test system.  I removed the Usec
precision as short queries disappear quickly enough for this not to be
interesting nor was there much point in sending the time from the
backend to the stat collector, as even a 5 second delay in receiving the
UDP packet didn't make any difference in the information I was looking
for -- enough information to make an snmp event about a rogue query or
connection.

Anyway, attached is what I've been using for curiosity sakes.  Updated
for -TIP and it compiles but I didn't test to see if it still works.

--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

Attachment

pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: [HACKERS] loading libraries on Postmaster startup
Next
From: Rod Taylor
Date:
Subject: Feature list correction