Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id D0A4A63493C for ; Tue, 2 Jun 2009 11:43:41 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 93955-06 for ; Tue, 2 Jun 2009 11:43:29 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mail.postgresql.org (Postfix) with ESMTP id 151A26348D5 for ; Tue, 2 Jun 2009 11:43:38 -0300 (ADT) Received: by qw-out-2122.google.com with SMTP id 8so4288706qwh.61 for ; Tue, 02 Jun 2009 07:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9ij8hinR9zzXxuGgKlGKNHBd8qy+gIDKmkokflJPb5A=; b=RkQ9rEoNfeTSvKAqWHiQl6TfEN5OjgR8GyH8lhHZ5yvsR6ipeKgiuvHOM5cpspb1fW WNlD0uGHkdPp5o36nyfu3ETRTxRjy1xCFfnTGb8G7YcFoE55bssmF1hPfyfodqLMuf7i 3xLHyqILxDyDpgWUJ0y0GqeVW96R6Rbo5iMUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VtK23bN4jgR/bwMSkz/NEQpRt31p/VL0kU0sW23JGaXQkOy/uqkrJNxxKHcFqTn+Aj zq1SynNSAI0Hyw1ure9R5yAI1znrq0BPNB5vBpApbCFl0xyUXkgxFsE5m5DfB6y/zVfV 2KPTNmLTNWN2ftJc/sNnr8Hkbvlk1y8lQ8Gew= MIME-Version: 1.0 Received: by 10.231.15.7 with SMTP id i7mr1802565iba.43.1243953816486; Tue, 02 Jun 2009 07:43:36 -0700 (PDT) In-Reply-To: <11613.1243952642@sss.pgh.pa.us> References: <1243914753.517210.131510259224.0.gpush@pingu> <10549.1243949503@sss.pgh.pa.us> <200906022352.01814.jk@ozlabs.org> <11313.1243951871@sss.pgh.pa.us> <11613.1243952642@sss.pgh.pa.us> Date: Tue, 2 Jun 2009 17:43:36 +0300 Message-ID: Subject: Re: [RFC,PATCH] SIGPIPE masking in local socket connections From: Marko Kreen To: Tom Lane Cc: Jeremy Kerr , pgsql-hackers@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.073 tagged_above=0 required=5 tests=AWL=0.073 X-Spam-Level: X-Archive-Number: 200906/149 X-Sequence-Number: 139204 On 6/2/09, Tom Lane wrote: > Marko Kreen writes: > > On 6/2/09, Tom Lane 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