Tom Lane wrote:
> Jan Wieck <janwieck@Yahoo.com> writes:
> >     What about a collector deamon, fired up by the postmaster and
> >     receiving UDP packets from the backends. Under heavy load, it
> >     might miss some statistic messages, well, but that's  not  as
> >     bad as having locks causing backends to loose performance.
>
> Interesting thought, but we don't want UDP I think; that just opens
> up a whole can of worms about checking access permissions and so forth.
> Why not a simple pipe?  The postmaster creates the pipe and the
> collector daemon inherits one end, while all the backends inherit the
> other end.

    I don't think so - though I haven't tested the following yet,
    but AFAIR it's correct.

    Have the postmaster creating two UDP sockets before it  forks
    off the collector. It can examine the peer addresses of both,
    so they don't need well known port numbers,  it  can  be  the
    randomly  ones  assigned  by  the kernel. Thus, we don't need
    SO_REUSE on them either.

    Now, since the collector is forked off by the postmaster,  it
    knows  the  peer  address  of the other socket. And since all
    backends get forked off from the postmaster as well,  they'll
    all  use  the  same  peer  address,  don't  they?  So all the
    collector has to look at is the sender address including port
    number  of  the  packets.  It needs to be what the postmaster
    examined, anything else is from someone else and goes to  bit
    heaven.  The  same  way the backends know where to send their
    statistics.

    If I'm right that in the case of fork()  all  children  share
    the  same  socket  with the same peer address, then it's even
    safe in the case the collector dies. The postmaster can still
    hold the collectors socket and will notice that the collector
    died (due to a wait() returning it's PID)  and  can  fire  up
    another one. Again some packets got lost (plus all the so far
    collected statistics, hmmm - aint that a cool  way  to  reset
    statistic  counters - killing the collector?), but it did not
    disturb any live backend in any way. They will never get  any
    signal,  don't  care  about what's done with their statistics
    and such. They just do their work...


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Thu, 15 Mar 2001 17:22:41 -0500 (EST)
Jan Wieck <JanWieck@Yahoo.com>
Re: Performance monitor signal handler