Re: Performance monitor signal handler - Mailing list pgsql-hackers

Jan Wieck <JanWieck@Yahoo.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
processesdoing 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
issufficient space               available in the pipe, write() will transfer all the data               and return the
numberof 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