From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | PostgreSQL HACKERS <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Performance monitor signal handler |
Date: | 2001-03-15 22:22:41 |
Message-ID: | 200103152222.RAA04268@jupiter.jw.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Jan Wieck <janwieck(at)Yahoo(dot)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(at)Yahoo(dot)com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2001-03-15 22:34:29 | Re: Performance monitor signal handler |
Previous Message | Tom Lane | 2001-03-15 22:11:19 | Re: Allowing WAL fsync to be done via O_SYNC |