On Sat, Jan 26, 2013 at 09:25:56AM +0900, Tatsuo Ishii wrote:
> Sorry for confusion.
>
> I knew an unamed portal only lasts until current transaction ends. I
> was confused in the case when no explicit transaction is used.
>
> At completion of each series of extended-query messages, the
> frontend should issue a Sync message.
>
> This is not actually true because Sync is not actually mandatory as
> Tom pointed out before. We could use a Flush message instead but it's
> another story. And next sentence says:
>
> This parameterless message causes the backend to close the current
> transaction if it's not inside a BEGIN/COMMIT transaction block
> ("close" meaning to commit if no error, or roll back if error).
>
> I did not understand this at first because if we are not inside a
> BEGIN/COMMIT transaction block, how does Sync close it? In my
> understanding each extended query message(parse/bind/execute) starts
> an internal transaction and does not close it until Sync issued(and
> Sync is mandatory according to the manual). So if we are not in an
> explicit transaction we cannot reuse unnamed portal because Sync
> closes the transaction, which in turn destroys the unnamed portal.
> This gave me a miss understanding that unnamed portal is destroyed
> even transaction is not explicitly closed.
>
> It would be nice if something like "unnamed portal will be destroyed
> by a Sync message if you are in an explicit transaction" is in our
> manual.
I am back to this issue and still confused. Perhaps if I give some
specific examples it will help.
Based on the current documentation, I assume that if you do an explicit
transaction (BEGIN WORK), Sync will not close any portals. For an
implicit transaction, I assume Sync will close all portals except FOR
HOLD named portals. Is this not how it behaves?
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
