Re: libpq connection timeout mismanagement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq connection timeout mismanagement
Date: 2018-08-13 17:16:29
Message-ID: 20525.1534180589@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> Patch does not "git apply", but is ok with "patch -p1". Compiles.

Yeah, as far as I can tell, "git apply" is very intolerant.

> The code suggests that timeout is always 2 or more
> if (timeout < 2) timeout = 2;
> but doc says "It is not recommended to use a timeout of less than 2
> seconds", which is inconsistent. It should read "Timeout is always set to
> at least 2 whatever the user asks.".

Agreed, changed the docs to clarify this.

> connect_timeout=2.9 is accepted and considered as meaning 2.
> connect_timeout=-10 or connect_timeout=two are also accepted and mean
> forever. Probably thanks to "atoi".

Right. As before, I'm not excited about rejecting trailing junk,
considering we never did before. It is kind of bogus that the
resolution of the timeout is only 1 second though --- maybe in
2002 that was fine, but today it seems strange. I'm tempted to
change the parameter to be floating point (parse with atof, say)
and allow millisecond precision. Then we'd not really need to
have the restriction about minimum delay.

That's a task for a different patch though. In the meantime,
pushed this one --- thanks for reviewing!

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-08-13 17:23:33 Re: libpq connection timeout mismanagement
Previous Message Alvaro Herrera 2018-08-13 17:15:07 Re: Temporary tables prevent autovacuum, leading to XID wraparound