From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Question regarding Sync message and unnamed portal |
Date: | 2012-10-01 15:37:21 |
Message-ID: | 25298.1349105841@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> The right thing to use if you're trying to interleave portal executions
>> like that is Flush, not Sync. Sync mainly adds a protocol
>> resynchronization point --- it's needed in case portal execution fails
>> partway through. (In which case you'll have lost both portals in the
>> transaction abort anyway.)
> Thanks for the suggestion. However, problem with using Flush is,
> backend never sends "Ready for Query" until Sync is sent. For frontend
> program "Ready for query" is important because 1) client knows session
> state, 2) "Ready for query" is a command boundary as stated in
> document.
[ shrug... ] RFQ is an acknowledgement of a sync point. It's useful
for clients that are too lazy to keep track of the protocol state in
great detail --- but if you're trying to interleave execution of two
portals, you need to keep track.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2012-10-01 16:06:19 | Re: CTE optimization fence on the todo list? |
Previous Message | Tom Lane | 2012-10-01 15:33:01 | Re: embedded list v3 |