Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group