Re: Millisecond-precision connect_timeout for libpq

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Millisecond-precision connect_timeout for libpq
Дата
Msg-id CAHyXU0zuv4JOtE4T4x136XwwMVsDEBevqHc7uyNuL+xLnNinnA@mail.gmail.com
обсуждение исходный текст
Ответ на Millisecond-precision connect_timeout for libpq  (ivan babrou <ibobrik@gmail.com>)
Список pgsql-hackers
On Wed, Jul 10, 2013 at 2:54 AM, ivan babrou <ibobrik@gmail.com> wrote:
> On 9 July 2013 19:17, Dmitriy Igrishin <dmitigr@gmail.com> wrote:
>>
>>
>>
>> 2013/7/9 Merlin Moncure <mmoncure@gmail.com>
>>>
>>> On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou <ibobrik@gmail.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@postgresql.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Kupershmidt
Дата:
Сообщение: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist