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-09-30 16:07:02 |
Message-ID: | 26489.1349021222@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:
> 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.
> 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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-30 16:57:32 | Re: embedded list v3 |
Previous Message | Thomas Munro | 2012-09-30 10:21:01 | pg_regress running for ~10 hours using 100% CPU |