Philip Warner wrote:
>
> But I prefer the UDP/Collector model anyway; it gives use greater
> flexibility + the ability to keep stats past backend termination, and,as
> you say, removes any possible locking requirements from the backends.
OK, did some tests...
The postmaster can create a SOCK_DGRAM socket at startup and
bind(2) it to "127.0.0.1:0", what causes the kernel to assign
a non-privileged port number that then can be read with
getsockname(2). No other process can have a socket with the
same port number for the lifetime of the postmaster.
If the socket get's ready, it'll read one backend message
from it with recvfrom(2). The fromaddr must be
"127.0.0.1:xxx" where xxx is the port number the kernel
assigned to the above socket. Yes, this is his own one,
shared with postmaster and all backends. So both, the
postmaster and the backends can use this one UDP socket,
which the backends inherit on fork(2), to send messages to
the collector. If such a UDP packet really came from a
process other than the postmaster or a backend, well then the
sysadmin has a more severe problem than manipulated DB
runtime statistics :-)
Running a 500MHz P-III, 192MB, RedHat 6.1 Linux 2.2.17 here,
I've been able to loose no single message during the parallel
regression test, if each backend sends one 1K sized message
per query executed, and the collector simply sucks them out
of the socket. Message losses start if the collector does a
per message idle loop like this:
for (i=0,sum=0;i<250000;i++,sum+=1);
Uh - not much time to spend if the statistics should at least
be half accurate. And it would become worse in SMP systems.
So that was a nifty idea, but I think it'd cause much more
statistic losses than I assumed at first.
Back to drawing board. Maybe a SYS-V message queue can serve?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
