Jan Wieck <[EMAIL PROTECTED]> writes:
> Does a pipe guarantee that a buffer, written with one atomic
> write(2), never can get intermixed with other data on the
> readers end?
Yes. The HPUX man page for write(2) sez:
o Write requests of {PIPE_BUF} bytes or less will not be
interleaved with data from other processes doing writes on the
same pipe. Writes of greater than {PIPE_BUF} bytes may have
data interleaved, on arbitrary boundaries, with writes by
other processes, whether or not the O_NONBLOCK flag of the
file status flags is set.
Stevens' _UNIX Network Programming_ (1990) states this is true for all
pipes (nameless or named) on all flavors of Unix, and furthermore states
that PIPE_BUF is at least 4K on all systems. I don't have any relevant
Posix standards to look at, but I'm not worried about assuming this to
be true.
> With message queues, this is guaranteed. Also, message queues
> would make it easy to query the collected statistics (see
> below).
I will STRONGLY object to any proposal that we use message queues.
We've already had enough problems with the ridiculously low kernel
limits that are commonly imposed on shmem and SysV semaphores.
We don't need to buy into that silliness yet again with message queues.
I don't believe they gain us anything over pipes anyway.
The real problem with either pipes or message queues is that backends
will block if the collector stops collecting data. I don't think we
want that. I suppose we could have the backends write a pipe with
O_NONBLOCK and ignore failure, however:
o If the O_NONBLOCK flag is set, write() requests will be
handled differently, in the following ways:
- The write() function will not block the process.
- A write request for {PIPE_BUF} or fewer bytes will have
the following effect: If there is sufficient space
available in the pipe, write() will transfer all the data
and return the number of bytes requested. Otherwise,
write() will transfer no data and return -1 with errno set
to EAGAIN.
Since we already ignore SIGPIPE, we don't need to worry about losing the
collector entirely.
Now this would put a pretty tight time constraint on the collector:
fall more than 4K behind, you start losing data. I am not sure if
a UDP socket would provide more buffering or not; anyone know?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
