Thread: getting pid of backend

Is there a way to read the pid of the actual backend from SQL? I know a
dirty workaround: 

setting debug=2, log_pid=yes in postgresql.conf;

writing a function doing this:

executing a 'SELECT a_generated_random_number';
while not found pidreading from the postmaster log waiting for a_generated_random_number.

Is there an easier method?

--                         Kov\'acs, Zolt\'an                        kovacsz@pc10.radnoti-szeged.sulinet.hu
          http://www.math.u-szeged.hu/~kovzol                        ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz
 

Kovacs,

> Is there an easier method?

Much easier.  Take a look at $PGDATA/postmaster.pid

-Josh

On Tue, 5 Mar 2002, Josh Berkus wrote:

> Kovacs,
> 
> > Is there an easier method?
> 
> Much easier.  Take a look at $PGDATA/postmaster.pid

I mean the current pid number of the actual connection. Not the postmaster
process, I need the pid of the currently running postgres. :-)

Regards,                        Kov\'acs, Zolt\'an                        kovacsz@pc10.radnoti-szeged.sulinet.hu
               http://www.math.u-szeged.hu/~kovzol
ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz

Kovacs Zoltan wrote:
> On Tue, 5 Mar 2002, Josh Berkus wrote:
> 
> > Kovacs,
> > 
> > > Is there an easier method?
> > 
> > Much easier.  Take a look at $PGDATA/postmaster.pid
> 
> I mean the current pid number of the actual connection. Not the postmaster
> process, I need the pid of the currently running postgres. :-)

You are going to love this one:test=> create function getpid() returns int as '/shlib/libc.so',        'getpid'
languagec;CREATEtest=> select getpid(); getpid --------   2971(1 row)
 

You may need to modify the libc.so path.

--  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
 

Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu> writes:
> I mean the current pid number of the actual connection. Not the postmaster
> process, I need the pid of the currently running postgres. :-)

I don't believe it's available as a SQL query, but libpq can tell you
what it is.

Probably a more interesting question is "why do you want to know?".
I can't offhand think of a really good reason to use the backend pid
for anything on the client side, other than distinguishing self-notifies
from other notifies, which is not something you can do at the SQL level
anyway.
        regards, tom lane

> Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu> writes:
> > I mean the current pid number of the actual connection. Not the
> postmaster
> > process, I need the pid of the currently running postgres. :-)
>
> I don't believe it's available as a SQL query, but libpq can tell you
> what it is.
>
> Probably a more interesting question is "why do you want to know?".
> I can't offhand think of a really good reason to use the backend pid
> for anything on the client side, other than distinguishing self-notifies
> from other notifies, which is not something you can do at the SQL level
> anyway.
>
>             regards, tom lane

We need the backend's pid in the backend side. The backend's pid is good to
figure out the client ip address and good for logging.

We need to log the connections and the Win32 exe-s to determine the
ownership relations between backends and programs. Unfortunately, there are
backends without programs, eating server resources in our production system.

Plus we need to connect the logs to existing user and system dictionary data
in the database so we want to log into database tables.

Do you think it's a silly thing?


Regards, Tibor Laszlo
ltibor@mail.tiszanet.hu