From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Non-blocking communication between a frontend and a backend (pqcomm) |
Date: | 2009-07-25 15:41:01 |
Message-ID: | 26107.1248536461@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jul 24, 2009 at 7:21 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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 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.
General-purpose facility *for what*? It's impossible to evaluate the
code without a definition of the purpose behind it.
What I actually think should come first is a spec for the client
protocol this is intended to support. It's not apparent to me at
the moment why the backend should need non-blocking read at all.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | A.M. | 2009-07-25 15:53:25 | Re: SE-PostgreSQL Specifications |
Previous Message | Tom Lane | 2009-07-25 15:06:37 | Re: SE-PostgreSQL Specifications |