RE: Timeout parameters - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Timeout parameters
Date
Msg-id 0A3221C70F24FB45833433255569204D1FBEC435@G01JPEXMBYT05
Whole thread Raw
In response to RE: Timeout parameters  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
From: Tsunakawa, Takayuki [mailto:tsunakawa.takay@jp.fujitsu.com]
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@lab.ntt.co.jp]
> > +    if (setsockopt(conn->sock, IPPROTO_TCP, TCP_USER_TIMEOUT,
> > +             (char *) &timeout, sizeof(timeout)) < 0 && errno !=
> > ENOPROTOOPT)
> > +    {
> > +        char        sebuf[256];
> > +
> > +        appendPQExpBuffer(&conn->errorMessage,
> > +                    libpq_gettext("setsockopt(TCP_USER_TIMEOUT)
> > failed: %s\n"),
> >
> > I suppose that the reason ENOPROTOOPT is excluded from error
> > condition is that the system call may fail with that errno on
> > older kernels, but I don't think that that justifies ignoring the
> > failure.
> 
> I think that's for the case where the modules is built on an OS that supports
> TCP_USER_TIMEOUT (#ifdef TCP_USER_TIMEOUT is true), and the module is used
> on an older OS that doesn't support TCP_USER_TIMEOUT.  I remember I was
> sometimes able to do such a thing on Linux and Solaris.  If we don't have
> to handle such usage, I agree about removing the special handling of
> ENOTPROTO.

Oops, I agree that we return an error even in the ENOPROTOOPT case, because setsockopt() is called only when the user
specifiestcp_user_timeout.
 


Regards
Takayuki Tsunakawa





pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: New vacuum option to do only freezing
Next
From: Fabien COELHO
Date:
Subject: RE: minimizing pg_stat_statements performance overhead