Re: Performance monitor signal handler

Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> 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.

That's good news - and maybe a Good Assumption (TM).

> > 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.

OK.

> 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.

That's not what the manpage said. It said that in the case
you're inside PIPE_BUF size and using O_NONBLOCK, you either
send complete messages or nothing, getting an EAGAIN then.

So we could do the same here and write to the pipe. In the
case we cannot, just count up and try again next year (or
so).

>
> 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?

Again, this ain't what the manpage said. If there's
sufficient space available in the pipe in combination with
that PIPE_BUF is at least 4K doesn't necessarily mean that
the pipes buffer space is 4K.

Well, what I'm missing is the ability to filter out
statistics reports on the backend side via msgrcv(2)s msgtype
:-(

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