Hi,
Thanks for the comment!
On Tue, Jul 28, 2009 at 12:27 AM, Tom Lane 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, and to
> the ex
Fujii Masao writes:
> On Sat, Jul 25, 2009 at 8:39 AM, Tom Lane 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
>>
Hi,
On Sat, Jul 25, 2009 at 8:39 AM, Tom Lane 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
> secure_poll, that mig
Hi,
On Sun, Jul 26, 2009 at 6:42 AM, Robert Haas 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 mark this returned w
On Sat, Jul 25, 2009 at 11:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 24, 2009 at 7:21 PM, Tom Lane 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 Sync
Robert Haas writes:
> On Fri, Jul 24, 2009 at 7:21 PM, Tom Lane 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 suggestion to submit
> separately any p
On Fri, Jul 24, 2009 at 7:21 PM, Tom Lane wrote:
> Fujii Masao writes:
>> On Wed, Jul 22, 2009 at 2:20 AM, Robert Haas 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 ac
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
Fujii Masao writes:
> On Wed, Jul 22, 2009 at 2:20 AM, Robert Haas 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 itself. It adds a bunch of code that is not
Hi,
On Wed, Jul 22, 2009 at 2:20 AM, Robert Haas 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 Pihlak wrote:
>> Here's my initial review of the non-blocking pqcomm patch. The
On Fri, Jul 17, 2009 at 5:26 PM, Martin Pihlak 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 non-blocking
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 pa
13 matches
Mail list logo
