Re: Question regarding Sync message and unnamed portal

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question regarding Sync message and unnamed portal
Date: 2012-10-01 05:04:00
Message-ID: 20121001.140400.329729302380702415.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> From the manual:
>> "An unnamed portal is destroyed at the end of the transaction"
>
> Actually, all portals are destroyed at end of transaction (unless
> they're from holdable cursors). Named or not doesn't enter into it.

We need to fix the document then.

>> From these statements, I would think #4 will fail in the following
>> sequence of commands because #3 closes transaction and it destroys
>> unnamed portal: 1)Parse/Bind creates unnamed portal,
>> 2)Parse/Bind/Execute creates named portal and executes, 3)Send Sync
>> message (because it is required in extended protocol), 4)Execute
>> unnamed portal created in #1.
>
> 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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2012-10-01 06:24:39 Re: doc patch for increase in shared_buffers
Previous Message john knightley 2012-10-01 04:52:34 Re: Extending range of to_tsvector et al