Re: send/receive buffer size

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Scott Harrington <scotth01(at)sns-usa(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: send/receive buffer size
Date: 2012-09-12 00:58:38
Message-ID: CADK3HHK=reNMvs6M+vd+YczAT=UQ0coFA8+22EeHAER70G46sg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

I've applied this patch with changes to use camelCase for
sendBufferSize, and receiveBufferSize to 9.2
Originally supplied by Bernd Helme

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Tue, Aug 21, 2012 at 7:08 PM, Scott Harrington <scotth01(at)sns-usa(dot)com> wrote:
> On Tue, 21 Aug 2012, Shijun Kong wrote:
>
>> I read a thread somewhere that somebody contributed a patch for adding
>> support of configurable send/receive buffer size. Did it ever commit into
>> master branch? I did not see any commit message about this change for last
>> 12 months.
>
>
> I wondered the same last weekend and found that the patch had NOT yet found
> its way into pgjdbc on github. In case it helps you, I've attached that old
> patch in a form that should apply cleanly against the latest sources (unless
> something's changed in the last 10 days).
>
> Before merging, maintainers would probably want to rename the property names
> (which have underscores in this patch) to better conform to the other driver
> properties which use camelcaps for the most part.
>
> I have also attached a "localAddress" patch that I find useful (I think I
> posted it myself a while ago, but in any case here's an updated patch that
> should apply more cleanly against recent sources).
>
> -Scott
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Devrim GÜNDÜZ 2012-09-12 08:36:28 9.2 driver
Previous Message Mikko Tiihonen 2012-09-11 17:38:35 Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal