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

Possible substitute for PostmasterIsAlive polling loops

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Possible substitute for PostmasterIsAlive polling loops
Date: 2011-02-23 21:54:20
Message-ID: 7701.1298498060@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
We've touched a few times on trying to get rid of the
sleep-awhile-and-check-for-something-to-do loops in PG's auxiliary
processes, mainly to satisfy people who complain about CPU power
consumption when idle.  I can see how most of the something-to-do
checks can be reimplemented using latches, but up to now there
didn't seem to be a good way to get rid of waking up every so often
to check if the postmaster was still there.  So it got my attention
when someone mentioned this Linux syscall on a Red Hat mailing list:

NAME
       prctl - operations on a process

SYNOPSIS
       #include <sys/prctl.h>

       int prctl(int option, unsigned long arg2, unsigned long arg3,
                 unsigned long arg4, unsigned long arg5);

...
       The first argument can be:
...

       PR_SET_PDEATHSIG (since Linux 2.1.57)
              Set  the  parent  process death signal of the calling process to
              arg2 (either a signal value in the  range  1..maxsig,  or  0  to
              clear).   This  is  the signal that the calling process will get
              when its parent dies.  This value is cleared for the child of  a
              fork(2).


IOW, at least on Linux, you *can* arrange to get a signal when your
parent process dies.

Not sure how ugly it'd be to use this call when available and a time
delay when not, but it's something to think about.

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-02-23 22:37:39
Subject: Re: WIP: cross column correlation ...
Previous:From: Tom LaneDate: 2011-02-23 21:30:04
Subject: Re: Binary in/out for aclitem

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