Skip site navigation (1) Skip section navigation (2)

[ psqlodbc-Bugs-1010541 ] applications crash with SIGPIPE

From: <noreply(at)pgfoundry(dot)org>
To: noreply(at)pgfoundry(dot)org
Subject: [ psqlodbc-Bugs-1010541 ] applications crash with SIGPIPE
Date: 2010-05-21 03:56:52
Message-ID: (view raw or whole thread)
Lists: pgsql-odbc
Bugs item #1010541, was opened at 2008-12-29 20:42
You can respond by visiting:

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Brian Feldman (brianfeldman)
Assigned to: Hiroshi Inoue (hinoue)
Summary: applications crash with SIGPIPE

Initial Comment:
Any time a PostgreSQL server is restarted, applications using the ODBC driver to connect to it will get a SIGPIPE and often crash because of it.  Libraries have no business generating SIGPIPE, so MSG_NOSIGNAL/MSG_NOSIGPIPE/etc. should be specified for the send(2) calls instead.


Comment By: Hiroshi Inoue (hinoue)
Date: 2009-01-04 03:01

I've just committed a change to CVS according to your

Hiroshi Inoue


Comment By: Brian Feldman (brianfeldman)
Date: 2009-01-02 17:30

Yes, it would simply be ideal, I think, to define a platform
specific SENDFLAGS and use that for all send() calls, i.e.
 * Do not generate SIGPIPE for applications that get
#if defined(MSG_NOSIGNAL)
#elif defined(MSG_NOSIGPIPE)
#define SENDFLAGS 0

It seems that Windows actually did not copy the socket
SIGPIPE design mistake from Unix.  If it did, I think it
would be appropriate to disable it there as well.  Some Unix
platforms don't have a way to disable SIGPIPE at all,
unfortunately, so it cannot be consistent.  Thank you for
your help!


Comment By: Hiroshi Inoue (hinoue)
Date: 2008-12-30 23:00

I can't such values in Windows. Is it related to *nix platforms? If so I would take care od it in the next release.


You can respond by visiting:

pgsql-odbc by date

Next:From: Lou PiccianoDate: 2010-05-21 12:04:58
Subject: Trouble installing on Windows XP?
Previous:From: noreplyDate: 2010-05-21 03:34:04
Subject: [ psqlodbc-Bugs-1010515 ] Small negative decimal values are mistaken for non-negative

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group