Skip site navigation (1) Skip section navigation (2)

Re: Added columns to pg_stat_activity

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>,Jan Wieck <JanWieck(at)Yahoo(dot)com>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Added columns to pg_stat_activity
Date: 2005-05-09 02:04:18
Message-ID: 427EC522.4010807@samurai.com (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane wrote:
> I think this argument is a red herring ... or at least it leads in a
> direction I find unacceptable.

I agree -- I was just pointing out the reason that, in the current 
design, there is cause to do things as Magnus' original patch did.

> We are already transmitting three more fields than necessary in every
> MsgHdr --- PID, database OID, and user ID --- and it will only get
> worse if we go down this path.

How about changing the statistics collector so that we only include a 
row in the statistics view when we receive the BESTART message? That 
would mean the BESTART message could include backend-start metadata 
(user ID, database ID, client address), and all other messages would 
only need enough header data to identify the backend process they are 
associated with (so perhaps backend id and process id).

Using the existing dead-backend hash table, we should be able to 
distinguish between the cases of "seen a message for a new backend 
before receiving its BESTART" and "seen a message for a dead backend 
after we've seen its BETERM".

-Neil

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2005-05-09 02:24:19
Subject: Re: Added columns to pg_stat_activity
Previous:From: Tom LaneDate: 2005-05-09 01:26:53
Subject: Re: Added columns to pg_stat_activity

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group