Re: getpid() function - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: getpid() function
Date
Msg-id 200208040338.g743c9328045@candle.pha.pa.us
Whole thread Raw
In response to Re: getpid() function  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: getpid() function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Let's take it out and wait to see if anyone really still wants it.
> 
> > Just when I am ready to throw it away, I come up with a use for the
> > function:
> 
> >     test=> select * from pg_stat_activity where procpid != backend_pid();
> 
> > This shows all activity _except_ my session, which pgmonitor or others
> > may want to use, and I can think of no other way to do it.
> 
> Hm.  Actually this seems like an argument for exposing MyBackendId, since
> what pg_stat_activity really depends on is BackendId.  But as that view
> is presently defined, you'd not be able to write
>     WHERE backendid = my_backend_id()
> because the view doesn't expose backendid.

Yes.

> > Comments?  Maybe this is why it should be called pg_backend_id and put
> > in the stat section.
> 
> *Please* don't call it pg_backend_id --- that invites confusion with
> BackendId which is a different thing.
> 
> I'd suggest pg_backend_pid.

Sorry, I mean pg_backend_pid.   I could expose backend_id but it may
confuse people so pid is probably better.  If you had the id, you could
use pg_stat_get_backend_pid() to get the pid.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CLUSTER and indisclustered
Next
From: Tom Lane
Date:
Subject: Re: CLUSTER and indisclustered