On Thu, Aug 6, 2015 at 03:15 AM, Michael Paquier
wrote:
>On Wed, Aug 5, 2015 at 11:53 PM, Bruce Momjian wrote:
>> On Wed, Jul 8, 2015 at 12:24:37PM -0400, Robbie Harwood wrote:
>>> > You update the documentation just for psql but your change effects any
>>> > libpq application if we go forward
Hi,
I would like allow specifying multiple host names for libpq to try to
connecting to. This is currently only supported if the host name resolves to
multiple addresses. Having the support for it without complex dns setup would
be much easier.
Example:
psql -h dbslave,dbmaster -p 5432 dbna
Kevin Wooten wrote:
> > On Nov 4, 2014, at 12:55 AM, Craig Ringer wrote:
> >
> > I have to say I like some aspects of how pgjdbc-ng is being done - in
> > particular use of Maven and being built around non-blocking I/O.
> >
> > OTOH, the use of Google Guava I find pretty inexplicable in a JDBC
>
> Craig Ringer wrote:
> On 11/02/2014 09:27 PM, Mikko Tiihonen wrote:
> > Is the following summary correct:
> > - the network protocol supports pipelinings
> Yes.
>
> All you have to do is *not* send a Sync message and be aware that the
> server will discard all
> > > From: Andres Freund
> > > On 2014-11-01 14:04:05 +0000, Mikko Tiihonen wrote:
> > > > I created a proof of concecpt patch for postgresql JDBC driver that
> > > > allows the caller to do pipelining of requests within a
> > > > transa
> From: Andres Freund
> On 2014-11-01 14:04:05 +, Mikko Tiihonen wrote:
> > I created a proof of concecpt patch for postgresql JDBC driver that
> > allows the caller to do pipelining of requests within a
> > transaction. The pipelining here means same as for HTTP: the
Mon Sep 17 00:00:00 2001
From: Mikko Tiihonen
Date: Sat, 1 Nov 2014 15:43:19 +0200
Subject: [PATCH] Example pipelined single-shot query
---
org/postgresql/core/QueryExecutor.java | 13 +++
org/postgresql/core/v2/QueryExecutorImpl.java | 5 +
org/postgresql/core/v3
Hi,
Currently the criteria on updating the F/B protocol is undefined. This makes it
hard to update the protocol going forward. It makes it also hard to write
library/driver/application implementations that will be more future proof to
future server versions.
Ideally the documentation for 9.4 (
On 12/14/2012 05:55 PM, Merlin Moncure wrote:
On Fri, Dec 14, 2012 at 9:33 AM, Mikko Tiihonen
wrote:
On 12/13/2012 12:19 AM, Peter Geoghegan wrote:
On 12 December 2012 22:11, Mikko Tiihonen
wrote:
noticed a "XXX: It might be worth considering using an atomic
fetch-and-add
instruction
On 12/13/2012 12:19 AM, Peter Geoghegan wrote:
On 12 December 2012 22:11, Mikko Tiihonen
wrote:
noticed a "XXX: It might be worth considering using an atomic fetch-and-add
instruction here, on architectures where that is supported." in lock.c
Here is my first try at using it
f0 83 2c 02 01 lock subl $0x1,(%rdx,%rax,1)
dd6: f3 c3 repz retq
dd8: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1)
ddf: 00
>From 958b04eb08603167dee2fe6684f9430f5b578f28 Mon Sep 17 00:00:00 2001
From: Mikko Tiihonen
Date: Wed, 1
On 01/25/2012 06:40 PM, Tom Lane wrote:
Marko Kreen writes:
On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
Huh? How can that work? If we decide to change the representation of
some other "well known type", say numeric, how do we decide whether a
client setting that bit is expectin
Previous title was: Add minor version to v3 protocol to allow changes without
breaking backwards compatibility
On 01/20/2012 04:45 AM, Noah Misch wrote:
On Thu, Jan 19, 2012 at 02:00:20PM -0500, Robert Haas wrote:
On Thu, Jan 19, 2012 at 10:37 AM, Noah Misch wrote:
I agree with Merlin; the
On 11/30/2011 06:52 PM, Merlin Moncure wrote:
On Mon, Nov 28, 2011 at 9:18 AM, Mikko Tiihonen
wrote:
Hi,
As discussed few days ago it would be beneficial if we could change the v3
backend<->client protocol without breaking backwards compatibility.
Here is a working patch that exp
side on feature 22, but the client only requests 21,23. The server must inform back that combination
21,23 is reduced to 21. And if then the client can not support 21 without 23 the final feature set will not contain 21 or 23.
-Mikko
commit d7ef5f1aef0941ec4b931f24745b65d77e7511e4
Author: Mikko Tii
On 11/24/2011 02:36 AM, Kevin Grittner wrote:
Oliver Jowett wrote:
Can we get a mechanism for minor protocol changes in this future
version? Something as simple as exchanging a list of protocol
features during the initial handshake (then use only features that
are present on both sides) would
Hi,
During conversion of the jdbc driver to use binary encoding when receiving
array objects from postgres it was noticed
that for example for int[] arrays the binary encoding is normally 30% to 200%
larger in bytes than the text encoding.
This was of concern to some users with slower links to
17 matches
Mail list logo
