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

Re: [patch] helps fe-connect.c handle -EINTR more gracefully

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Ford <david(at)blue-labs(dot)org>, Brent Verner <brent(at)rcfile(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] helps fe-connect.c handle -EINTR more gracefully
Date: 2001-10-28 19:16:05
Message-ID: Pine.LNX.4.30.0110281348510.619-100000@peter.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane writes:

> AFAICT the client-side libpq doesn't (and shouldn't) touch signal
> handling at all, except for a couple of places in the print routines
> that temporarily block SIGPIPE.

Which was my point.

> Since we deal happily with EINTR for most of the frontend socket calls,
> I don't see a reason not to cope with it for connect() too.  I am
> somewhat concerned about what exactly it means for a non-blocking
> connect, however.  Maybe it doesn't mean anything, and we could treat
> it the same as EINPROGRESS.

I feel that if the user installed his signal handlers to interrupt system
calls then he probably had a reason for it, possibly because of the timing
aspects of his application.  Thus, it shouldn't be libpq's task to
override that decision.  If the user doesn't want system calls to be
interrupted, then he should install the signal handlers in the proper way.
If he doesn't know how to do that, he needs to educate himself, that's
all.

-- 
Peter Eisentraut   peter_e(at)gmx(dot)net   http://funkturm.homeip.net/~peter


In response to

Responses

pgsql-hackers by date

Next:From: Jean-Michel POUREDate: 2001-10-28 19:18:41
Subject: Re: Ultimate DB Server
Previous:From: Olivier PRENANTDate: 2001-10-28 18:32:11
Subject: Regression error on unixware 7 and open unix 8

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