Re: Millisecond-precision connect_timeout for libpq

On Wed, Jul 10, 2013 at 2:54 AM, ivan babrou <ibobrik(at)gmail(dot)com> wrote:
> On 9 July 2013 19:17, Dmitriy Igrishin <dmitigr(at)gmail(dot)com> wrote:
>>
>>
>>
>> 2013/7/9 Merlin Moncure <mmoncure(at)gmail(dot)com>
>>>
>>> On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou <ibobrik(at)gmail(dot)com> wrote:
>>> > Hi, guys! I made a quick patch to support floating number in
>>> > connect_timeout param for libpq. This will treat floating number as
>>> > seconds so this is backwards-compatible. I don't usually write in C,
>>> > so there may be mistakes. Could you review it and give me some
>>> > feedback?
>>>
>>> First thing that jumps into my head: why not use asynchronous
>>> connection (PQconnectStart, etc) and code the timeout on top of that?
>>
>> +1.
>>>
>>>
>>> merlin
>>>
>>>
>>> --
>>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-hackers
>>
>>
>>
>>
>> --
>> // Dmitriy.
>>
>
> Doesn't look like straightforward solution for me. In my case existing
> drivers will benefit from my patch, in async case they should be
> rewritten. We don't use libpq directly, we use native pgsql module
> from php.
>
> Even with that, kernel can wait for milliseconds — why should we limit
> precision 1000x times and reinvent milliseconds again in userspace?

Fair point. Although I still agree with Tom in the sense that if I
were in your shoes I would be reconsidering certain parts of the
connection stack since you have such demanding requirements; even with
this solved I think other issues are lurking right around the corner.
That said, I did scan your patch briefly and noted it only changed
internal API functions and seems pretty straightforward. I withdraw my
objection.

merlin