Обсуждение: Re: [BUGS] BUG #1467: fe_connect doesn't handle EINTR right

Поиск
Список
Период
Сортировка

Re: [BUGS] BUG #1467: fe_connect doesn't handle EINTR right

От
Bruce Momjian
Дата:
Would someone comment on this bug report from February?  I can confirm
the code is unchanged and is in function fe-connect.c::PQconnectPoll().

---------------------------------------------------------------------------

Florian Hars wrote:
> 
> The following bug has been logged online:
> 
> Bug reference:      1467
> Logged by:          Florian Hars
> Email address:      hars@bik-gmbh.de
> PostgreSQL version: 8.0.1
> Operating system:   All
> Description:        fe_connect doesn't handle EINTR right
> Details: 
> 
> The file pgsql/src/interfaces/libpq/fe-connect.c contains the code fragment
> 
> retry_connect:
>   if (connect(conn->sock, addr_cur->ai_addr,
>                       addr_cur->ai_addrlen) < 0)
>   {
>     if (SOCK_ERRNO == EINTR)
>     /* Interrupted system call - just try again */
>         goto retry_connect;
>   }
> 
> This is not in accordance with a strict legalistic reading of the POSIX
> spec, according to which connect is not restartable so that you have to use
> select or poll after connect returned with EINTR.
> 
> See
> http://www.eleves.ens.fr:8080/home/madore/computers/connect-intr.html
> for the ugly details, your code should work on Linux, but not on Solaris or
> (Free|Open)BSD.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: [BUGS] BUG #1467: fe_connect doesn't handle EINTR right

От
Tom Lane
Дата:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Would someone comment on this bug report from February?

The report scored about zero out of zero IMHO: neither an actual report
of field trouble, nor a clear explanation of the supposed trouble, nor
a specific proposal what to do about it.

Without actual field trouble reports I am disinclined to touch the code
anyway ... chasing after unproven portability issues is an unprofitable
pursuit in my experience, since you can have no way to know if you've
actually fixed whatever real bug may exist.
        regards, tom lane