Is there any hope to see it in libpq? If so, can anyone review latest
version of my patch?
On 10 July 2013 11:49, ivan babrou wrote:
> On 9 July 2013 18:43, Andres Freund wrote:
>> On 2013-07-05 21:28:59 +0400, ivan babrou wrote:
>>> Hi, guys! I made a quick patch to support floating number in
>
On 2013-07-15 16:34:07 +0400, ivan babrou wrote:
> Is there any hope to see it in libpq? If so, can anyone review latest
> version of my patch?
A littlebit of patience please. There are heaps of other patches still
being reviewed that have been posted earlier than yours ;). I know it
can be frustr
On 07/09/2013 01:18 PM, Merlin Moncure wrote:
> On Fri, Jul 5, 2013 at 3:01 PM, Josh Berkus wrote:
>> It's fairly common with certain kinds of apps, including Rails and PHP.
>> This is one of the reasons why we've discussed having a kind of
>> stripped-down version of pgbouncer built into Postgre
On 9 July 2013 18:43, Andres Freund wrote:
> On 2013-07-05 21:28:59 +0400, ivan babrou 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
On 9 July 2013 19:17, Dmitriy Igrishin wrote:
>
>
>
> 2013/7/9 Merlin Moncure
>>
>> On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou 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
On Wed, Jul 10, 2013 at 2:54 AM, ivan babrou wrote:
> On 9 July 2013 19:17, Dmitriy Igrishin wrote:
>>
>>
>>
>> 2013/7/9 Merlin Moncure
>>>
>>> On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou wrote:
>>> > Hi, guys! I made a quick patch to support floating number in
>>> > connect_timeout param for
On Fri, Jul 5, 2013 at 3:01 PM, Josh Berkus wrote:
> On 07/05/2013 12:26 PM, Tom Lane wrote:
>> ivan babrou writes:
>>> If you can figure out that postgresql is overloaded then you may
>>> decide what to do faster. In our app we have very strict limit for
>>> connect time to mysql, redis and othe
On 9 July 2013 17:59, Markus Wanner wrote:
> Ian,
>
> On 07/05/2013 07:28 PM, ivan babrou wrote:
>> - /*
>> - * Rounding could cause connection to fail; need at
>> least 2 secs
>> - */
>
> You removed this above comment... please check
On 9 July 2013 12:20, Markus Wanner 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 norma
On 9 July 2013 11:05, Markus Wanner wrote:
> On 07/08/2013 08:31 PM, ivan babrou wrote:
>> Seriously, I don't get why running 150 poolers is easier.
>
> Did you consider running pgbouncer on the database servers?
>
> Regards
>
> Markus Wanner
Database server lost network — boom, 2 seconds delay.
2013/7/9 Merlin Moncure
> On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou 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 t
On 2013-07-05 21:28:59 +0400, ivan babrou 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 i
Ian,
On 07/05/2013 07:28 PM, ivan babrou wrote:
> - /*
> - * Rounding could cause connection to fail; need at
> least 2 secs
> - */
You removed this above comment... please check why it's there. The
relevant revision seems to be:
###
On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou 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 revi
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.
None the less, I now agree with you: we recommend a pooler, which may be
capable
On 07/08/2013 08:31 PM, ivan babrou wrote:
> Seriously, I don't get why running 150 poolers is easier.
Did you consider running pgbouncer on the database servers?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Jul 8, 2013, at 1:31 PM, ivan babrou wrote:
> On 8 July 2013 20:40, David E. Wheeler wrote:
>> On Jul 8, 2013, at 7:44 AM, ivan babrou wrote:
>>
Can you tell me why having ability to specify more accurate connect
timeout is a bad idea?
>>>
>>> Nobody answered my question yet.
>>
On 8 July 2013 20:40, David E. Wheeler wrote:
> On Jul 8, 2013, at 7:44 AM, ivan babrou wrote:
>
>>> Can you tell me why having ability to specify more accurate connect
>>> timeout is a bad idea?
>>
>> Nobody answered my question yet.
>
> From an earlier post by Tom:
>
>> What exactly is the use
Le lundi 8 juillet 2013 18:40:29, David E. Wheeler a écrit :
> On Jul 8, 2013, at 7:44 AM, ivan babrou wrote:
> >> Can you tell me why having ability to specify more accurate connect
> >> timeout is a bad idea?
> >
> > Nobody answered my question yet.
>
> From an earlier post by Tom:
> > What ex
On Jul 8, 2013, at 7:44 AM, ivan babrou wrote:
>> Can you tell me why having ability to specify more accurate connect
>> timeout is a bad idea?
>
> Nobody answered my question yet.
From an earlier post by Tom:
> What exactly is the use case for that? It seems like extra complication
> for som
On 5 July 2013 23:47, ivan babrou wrote:
> On 5 July 2013 23:26, Tom Lane wrote:
>> ivan babrou writes:
>>> If you can figure out that postgresql is overloaded then you may
>>> decide what to do faster. In our app we have very strict limit for
>>> connect time to mysql, redis and other services,
On 5 July 2013 23:26, Tom Lane wrote:
> ivan babrou writes:
>> If you can figure out that postgresql is overloaded then you may
>> decide what to do faster. In our app we have very strict limit for
>> connect time to mysql, redis and other services, but postgresql has
>> minimum of 2 seconds. Whe
"Joshua D. Drake" writes:
> On 7/5/2013 1:01 PM, Josh Berkus wrote:
>> This is one of the reasons why we've discussed having a kind of
>> stripped-down version of pgbouncer built into Postgres as a connection
>> manager. If it weren't valuable to be able to relocate pgbouncer to
>> other hosts, I
On 7/5/2013 1:01 PM, Josh Berkus wrote:
If you are issuing a fresh connection for each sub-100ms query, you're
doing it wrong anyway ...
It's fairly common with certain kinds of apps, including Rails and PHP.
This is one of the reasons why we've discussed having a kind of
stripped-down version
On 07/05/2013 12:26 PM, Tom Lane wrote:
> ivan babrou writes:
>> If you can figure out that postgresql is overloaded then you may
>> decide what to do faster. In our app we have very strict limit for
>> connect time to mysql, redis and other services, but postgresql has
>> minimum of 2 seconds. Wh
ivan babrou writes:
> If you can figure out that postgresql is overloaded then you may
> decide what to do faster. In our app we have very strict limit for
> connect time to mysql, redis and other services, but postgresql has
> minimum of 2 seconds. When processing time for request is under 100ms
If you can figure out that postgresql is overloaded then you may
decide what to do faster. In our app we have very strict limit for
connect time to mysql, redis and other services, but postgresql has
minimum of 2 seconds. When processing time for request is under 100ms
on average sub-second timeout
ivan babrou writes:
> Hi, guys! I made a quick patch to support floating number in
> connect_timeout param for libpq.
What exactly is the use case for that? It seems like extra complication
for something with little if any real-world usefulness.
regards, tom lane
--
S
28 matches
Mail list logo
