Re: Non-blocking communication between a frontend and a backend (pqcomm)

On Fri, Jul 24, 2009 at 7:21 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>> On Wed, Jul 22, 2009 at 2:20 AM, Robert Haas<robertmhaas(at)gmail(dot)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 itself.  It adds a bunch of code that is not used anywhere and hence
> can't be tested, in service of goals explained nowhere, but presumably
> part of some other patch that hasn't been reviewed and might or might
> not get accepted when it is presented.  The only thing that's really
> clear is that it pokes holes in the abstraction (such as it is)
> presented by pqcomm.c.
>
> The reason I want to see the calling code is that I doubt this is a very
> useful API extension as-is.  I can see the point of probing to see if
> any more bytes are available, but it's not clear that there is a reason
> to collect only part of a message once the client has sent one.  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.
>
> 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 parts that are separately committable, but that doesn't
seem to be the case given your comments here. I guess the question is
whether it's necessary and/or desirable to put in the effort to create
a general-purpose facility, or whether we should be satisfied with the
minimum level of infrastructure necessary to support Synch Rep and
just incorporate it into that patch.

Thoughts?

...Robert