Hi,
Thanks for the comment!
On Tue, Jul 28, 2009 at 12:27 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Well, actually, this description perfectly illustrates my basic
complaint: the patch breaks the API abstraction provided by pqcomm.c.
Callers are encouraged/forced to deal with the next layer down,
Hi,
On Sun, Jul 26, 2009 at 6:42 AM, Robert Haasrobertmh...@gmail.com wrote:
OK, I agree, I can't see what this is for either from the code that is
here. I think I read a little more meaning into the title of the
patch than was actually there. It seems like the appropriate thing to
do is
Hi,
On Sat, Jul 25, 2009 at 8:39 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Oh, another gripe: I'll bet a nickel that this doesn't work very nicely
under SSL. Bytes available on the socket doesn't necessarily equate to
decrypted payload bytes being available. Depending on how you're using
Fujii Masao masao.fu...@gmail.com writes:
On Sat, Jul 25, 2009 at 8:39 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Oh, another gripe: I'll bet a nickel that this doesn't work very nicely
under SSL. Bytes available on the socket doesn't necessarily equate to
decrypted payload bytes being available.
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 24, 2009 at 7:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I think you should just submit this with the code that uses it, so we
can evaluate whether the overall concept is a good one or not.
This was split out from Synch Rep based on my
On Sat, Jul 25, 2009 at 11:41 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 24, 2009 at 7:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I think you should just submit this with the code that uses it, so we
can evaluate whether the overall concept is a
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Jul 22, 2009 at 2:20 AM, Robert Haasrobertmh...@gmail.com wrote:
Are you planning to update this patch based on Martin's review?
Sure. Attached is an updated patch.
I looked at this patch. I don't see how we can consider accepting it
by
I wrote:
I am also thinking that if you do need the ability to get control back
without blocking on the socket, you probably will need that for writes
as well as reads; and this patch doesn't cover the write case.
Oh, another gripe: I'll bet a nickel that this doesn't work very nicely
under
On Fri, Jul 24, 2009 at 7:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Jul 22, 2009 at 2:20 AM, Robert Haasrobertmh...@gmail.com wrote:
Are you planning to update this patch based on Martin's review?
Sure. Attached is an updated patch.
I looked
Hi,
On Wed, Jul 22, 2009 at 2:20 AM, Robert Haasrobertmh...@gmail.com wrote:
Fujii Masao,
Are you planning to update this patch based on Martin's review?
Sure. Attached is an updated patch.
On Fri, Jul 17, 2009 at 5:26 PM, Martin Pihlakmartin.pih...@gmail.com wrote:
Here's my initial
On Fri, Jul 17, 2009 at 5:26 PM, Martin Pihlakmartin.pih...@gmail.com wrote:
Fujii Masao wrote:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00191.php
In line with Robert's suggestion, I submit non-blocking pqcomm patch
as a self-contained one.
Here's my initial review of the
Fujii Masao wrote:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00191.php
In line with Robert's suggestion, I submit non-blocking pqcomm patch
as a self-contained one.
Here's my initial review of the non-blocking pqcomm patch. The patch applies
cleanly and passes regression.
Hi,
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00191.php
In line with Robert's suggestion, I submit non-blocking pqcomm patch
as a self-contained one.
This patch provides support for non-blocking communication between
a frontend and a backend. The upcoming synchronous replication
13 matches
Mail list logo
