From: | L J Bayuk <ljb220(at)mindspring(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: pgin.tcl pg_exec_prepared slow (was: Released...) |
Date: | 2004-07-12 01:33:04 |
Message-ID: | 20040712013304.GA574@bxlbisnugqvi.mindspring.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
On Fri, Jul 09, 2004 at 08:07:56PM -0400, Tom Lane wrote:
> L J Bayuk <ljb220(at)mindspring(dot)com> writes:
> > I just haven't decided
> > whether to flush before reading, or flush after all messages that need a
> > response (I think: Startup, PasswordMessage, Query, Sync, CopyDone, and
> > FunctionCall are the ones I use).
>
> You seem to have quite missed my point. If you decide to flush on the
> basis of flush-after-certain-message-types-are-sent, then the types to
> flush after are precisely Sync and Flush. If you think you want
> something different, you are wrong and should think again (or more
> likely, insert Flush messages into the outgoing stream at the places
> where you want a flush to occur). There is no point in flushing after
> any other message type because the backend won't flush its response.
>...
Yes, I must be missing your point, unless you are talking only about the
Extended Query mode. Surely outside of Extended Query mode (Startup, Basic
Query mode, Function Call) the client must flush output after (at least)
the messages I listed above. That's what I get from the protocol
documentation, what works in practice, and network traces.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-07-12 02:02:52 | Re: pgin.tcl pg_exec_prepared slow (was: Released...) |
Previous Message | Tom Lane | 2004-07-10 00:07:56 | Re: pgin.tcl pg_exec_prepared slow (was: Released...) |