Re: [HACKERS] query log corrupted-looking entries

> >> Hmm. If the messages are less than PIPE_BUF bytes long
> (4096 bytes
> >> on
> >> Linux) then the writes are supposed to be atomic.
>
> > Some of them involve long messages (>4K), but there are
> many that do
> > not (like the ones I had posted at the start of this thread).
>
> I checked around with some kernel/glibc gurus in Red Hat, and
> the consensus seemed to be that we'd be better off to bypass
> fprintf() and just send message strings to stderr using
> write() --- ie, instead of elog.c doing
>
> fprintf(stderr, "%s", buf.data);
>
> do
>
> write(fileno(stderr), buf.data, strlen(buf.data));
>
> Anyone have any comments on possible portability risks? In
> particular, will this work on Windows?

Should work fine on Windows. fileno() is deprecated however, with the
following comment:
C:\Program Files\Microsoft Visual Studio
8\VC\INCLUDE\stdio.h(688) : see
declaration of 'fileno'
Message: 'The POSIX name for this item is deprecated. Instead,
use the ISO C++ conformant name: _fileno. See online help for details.'

It still works, and there is a define to get around that warning though,
so it's definitly not critical.

//Magnus