Re: Millisecond-precision connect_timeout for libpq - Mailing list pgsql-hackers

From ivan babrou
Subject Re: Millisecond-precision connect_timeout for libpq
Date
Msg-id CANWdNRA5wsmvBC=-6BeZnt-zOhHrogdpM97L136omDfWK45o5w@mail.gmail.com
Whole thread Raw
In response to Re: Millisecond-precision connect_timeout for libpq  (Markus Wanner <markus@bluegap.ch>)
List pgsql-hackers
On 9 July 2013 12:20, Markus Wanner <markus@bluegap.ch> wrote:
> On 07/09/2013 09:15 AM, ivan babrou wrote:
>> Database server lost network — boom, 2 seconds delay. What's the point then?
>
> Oh, I see. Good point. It could still improve connection time during
> normal operation, though.

Connection time during normal operation is 1.5ms which is fast enough for now.

> None the less, I now agree with you: we recommend a pooler, which may be
> capable of millisecond timeouts, but arguably is vastly more complex
> than the proposed patch. And it even brings its own set of gotchas (lots
> of connections). I guess I don't quite buy the complexity argument, yet.

Pooler isn't capable of millisecond timeouts. At least I don't see how
could I understand that pooler is dead in 50ms.

> Sure, gettimeofday() is subject to clock adjustments. But so is time().
> And if you're setting timeouts that low, you probably know what you're
> doing (or at least care about latency a lot). Or is gettimeofday() still
> considerably slower on certain architectures or in certain scenarios?
> Where's the complexity?

There's no complexity here :)

> Regards
>
> Markus Wanner

--
Regards, Ian Babrou
http://bobrik.name http://twitter.com/ibobrik skype:i.babrou



pgsql-hackers by date:

Previous
From: ivan babrou
Date:
Subject: Re: Millisecond-precision connect_timeout for libpq
Next
From: Robins Tharakan
Date:
Subject: Re: Patch to add regression tests for SCHEMA