On 6/2/09, Tom Lane <t...@sss.pgh.pa.us> wrote: > Marko Kreen <mark...@gmail.com> writes: > > On 6/2/09, Tom Lane <t...@sss.pgh.pa.us> wrote: > > >> We've had problems before with userland headers not being in sync > >> with what the kernel knows. > > > Well, we could just test in configure perhaps? > > > The single most common way to get into that kind of trouble is to > compile on machine A then install the executables on machine B with > a different kernel. So a configure test wouldn't give me any warm > feeling at all.
Agreed. Another problem would be cross-compilation. > A feature that is exercised via setsockopt is probably fairly safe, > since you can check for failure of the setsockopt call and then do > it the old way. MSG_NOSIGNAL is a recv() flag, no? The question > is whether you could expect that the recv() would fail if it had > any unrecognized flags. Not sure if I trust that. SO_NOSIGPIPE > seems safer. send(). The question is if the kernel would give error (good) or simply ignore it (bad). I guess with MSG_NOSIGNAL only safe way is to hardcode working OSes. Are there any OS-es that have MSG_NOSIGNAL but not SO_NOSIGPIPE? *grep* Eh, seems like Linux is such OS... But I also see it existing as of Linux 2.2.0 in working state, so should be safe to use on linux despite the kernel version. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
