Thread: Question regarding Sync message and unnamed portal
From the manual: "An unnamed portal is destroyed at the end of the transaction" "At completion of each series of extended-query messages, the frontend should issue a Sync message. This parameterless message causes the backend to close the current transaction if it's not inside a BEGIN/COMMIT transaction block" 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. If this is true, that means unnamed portal execution and named portal execution cannot be mixed unless they are inside an explicit transaction. IMO this should be described in the document. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
Tatsuo Ishii <ishii@postgresql.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
> Tatsuo Ishii <ishii@postgresql.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
Tatsuo Ishii <ishii@postgresql.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
On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote: > > Tatsuo Ishii <ishii@postgresql.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. I looked into this. The text reads: If successfully created, a named prepared-statement object lasts tillthe end of the current session, unless explicitly destroyed. An unnamedprepared statement lasts only until the next Parse statement specifyingthe unnamed statement as destinationis issued. While the first statement does say "named", the next sentence says "unnamed", so I am not sure we can make this any clearer. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote: >> > Tatsuo Ishii <ishii@postgresql.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. > > I looked into this. The text reads: > > If successfully created, a named prepared-statement object lasts till > the end of the current session, unless explicitly destroyed. An unnamed > prepared statement lasts only until the next Parse statement specifying > the unnamed statement as destination is issued. > > While the first statement does say "named", the next sentence says > "unnamed", so I am not sure we can make this any clearer. I'm not sure what this has to do with the previous topic. Aren't a prepared statement and a portal two different things? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote: > On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian <bruce@momjian.us> wrote: > > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote: > >> > Tatsuo Ishii <ishii@postgresql.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. > > > > I looked into this. The text reads: > > > > If successfully created, a named prepared-statement object lasts till > > the end of the current session, unless explicitly destroyed. An unnamed > > prepared statement lasts only until the next Parse statement specifying > > the unnamed statement as destination is issued. > > > > While the first statement does say "named", the next sentence says > > "unnamed", so I am not sure we can make this any clearer. > > I'm not sure what this has to do with the previous topic. Aren't a > prepared statement and a portal two different things? Oops, thanks. Here is the right paragraph, same issue: If successfully created, a named portal object lasts till the end of the current transaction, unless explicitly destroyed. An unnamed portal is destroyed at the end of the transaction, or as soon as the next Bind statement specifyingthe unnamed portal as destination is issued. (Note -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote: >> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian <bruce@momjian.us> wrote: >> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote: >> >> > Tatsuo Ishii <ishii@postgresql.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. >> > >> > I looked into this. The text reads: >> > >> > If successfully created, a named prepared-statement object lasts till >> > the end of the current session, unless explicitly destroyed. An unnamed >> > prepared statement lasts only until the next Parse statement specifying >> > the unnamed statement as destination is issued. >> > >> > While the first statement does say "named", the next sentence says >> > "unnamed", so I am not sure we can make this any clearer. >> >> I'm not sure what this has to do with the previous topic. Aren't a >> prepared statement and a portal two different things? > > Oops, thanks. Here is the right paragraph, same issue: > > If successfully created, a named portal object lasts till the end of the > current transaction, unless explicitly destroyed. An unnamed portal is > destroyed at the end of the transaction, or as soon as the next Bind > statement specifying the unnamed portal as destination is issued. (Note OK. Well, that seems clear enough. I'm not sure what it has to do with the original complaint, though, because I don't quite understand the original complaint, which seems to involve not only when portals are destroyed but also what effect Sync messages have. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Jan 25, 2013 at 03:24:27PM -0500, Robert Haas wrote: > On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian <bruce@momjian.us> wrote: > > On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote: > >> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian <bruce@momjian.us> wrote: > >> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote: > >> >> > Tatsuo Ishii <ishii@postgresql.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. > >> > > >> > I looked into this. The text reads: > >> > > >> > If successfully created, a named prepared-statement object lasts till > >> > the end of the current session, unless explicitly destroyed. An unnamed > >> > prepared statement lasts only until the next Parse statement specifying > >> > the unnamed statement as destination is issued. > >> > > >> > While the first statement does say "named", the next sentence says > >> > "unnamed", so I am not sure we can make this any clearer. > >> > >> I'm not sure what this has to do with the previous topic. Aren't a > >> prepared statement and a portal two different things? > > > > Oops, thanks. Here is the right paragraph, same issue: > > > > If successfully created, a named portal object lasts till the end of the > > current transaction, unless explicitly destroyed. An unnamed portal is > > destroyed at the end of the transaction, or as soon as the next Bind > > statement specifying the unnamed portal as destination is issued. (Note > > OK. Well, that seems clear enough. I'm not sure what it has to do > with the original complaint, though, because I don't quite understand > the original complaint, which seems to involve not only when portals > are destroyed but also what effect Sync messages have. Yes, I am confused too. Unless someone replies, we can consider this closed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
> Oops, thanks. Here is the right paragraph, same issue:
> If successfully created, a named portal object lasts till the end of the
> current transaction, unless explicitly destroyed. An unnamed portal is
> destroyed at the end of the transaction, or as soon as the next Bind
> statement specifying the unnamed portal as destination is issued. (Note
What is the issue exactly? Seems clear and correct to me ... but then,
I think I wrote this text, a long time ago.
regards, tom lane
On Fri, Jan 25, 2013 at 03:29:17PM -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Oops, thanks. Here is the right paragraph, same issue: > > > If successfully created, a named portal object lasts till the end of the > > current transaction, unless explicitly destroyed. An unnamed portal is > > destroyed at the end of the transaction, or as soon as the next Bind > > statement specifying the unnamed portal as destination is issued. (Note > > What is the issue exactly? Seems clear and correct to me ... but then, > I think I wrote this text, a long time ago. Tatsuo's complain was that on sentence said "named portal", while all portals are closed on transaction end. However, "unnamed portal" is named in the next sentence, so it seems OK. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
> On Fri, Jan 25, 2013 at 03:24:27PM -0500, Robert Haas wrote:
>> On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> > On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote:
>> >> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> >> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
>> >> >> > Tatsuo Ishii <ishii@postgresql.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.
>> >> >
>> >> > I looked into this. The text reads:
>> >> >
>> >> > If successfully created, a named prepared-statement object lasts till
>> >> > the end of the current session, unless explicitly destroyed. An unnamed
>> >> > prepared statement lasts only until the next Parse statement specifying
>> >> > the unnamed statement as destination is issued.
>> >> >
>> >> > While the first statement does say "named", the next sentence says
>> >> > "unnamed", so I am not sure we can make this any clearer.
>> >>
>> >> I'm not sure what this has to do with the previous topic. Aren't a
>> >> prepared statement and a portal two different things?
>> >
>> > Oops, thanks. Here is the right paragraph, same issue:
>> >
>> > If successfully created, a named portal object lasts till the end of the
>> > current transaction, unless explicitly destroyed. An unnamed portal is
>> > destroyed at the end of the transaction, or as soon as the next Bind
>> > statement specifying the unnamed portal as destination is issued. (Note
>>
>> OK. Well, that seems clear enough. I'm not sure what it has to do
>> with the original complaint, though, because I don't quite understand
>> the original complaint, which seems to involve not only when portals
>> are destroyed but also what effect Sync messages have.
>
> Yes, I am confused too. Unless someone replies, we can consider this
> closed.
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
transactionblock ("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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
Tatsuo Ishii-4 wrote
>
> 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.
>
> If this is true, that means unnamed portal execution and named portal
> execution cannot be mixed unless they are inside an explicit
> transaction. IMO this should be described in the document.
My relatively uninformed conclusions from reading this thread and
documentation excerpts:
Correct.
In the absence of an explicit transaction only a single logical query can be
executed "per transaction". #2 should be disallowed, though, as opposed to
#4 failing since the second PARSE implies a second logical query being
formed which should not occur outside an explicit transaction.
"At completion of each series of extended-query messages, the frontend
should issue a Sync message."
I take this phrase to mean that a logical sequence is defined as:
PARSE -> (BIND -> EXECUTE){1,} -> SYNC
If you are within an explicit transaction you are brought back to point
where the next PARSE can be issued and thus a new statement - within the
same transaction - can be issued. If you are not within an explicit
transaction the SYNC effectively causes a "COMMIT;" to be issued on the
back-end thus the unnamed statement and unnamed portal are both closed. If
the resultant portal is named and defined with "FOR HOLD" the named portal
will continue to exist while the named (or unnamed for that matter)
statement will be closed.
The documentation makes the assumption that you understand the "single
statement" nature of implicit transactions. Given the level of knowledge
needed to operate with the frontend protocol this is not necessarily
unreasonable. I guess my question is whether the backend fails in the
situation of an implicit transaction and two PARSE messages without an
intervening SYNC. If not then when is it reasonable to issue two PARSE
statements in this manner?
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Question-regarding-Sync-message-and-unnamed-portal-tp5726023p5770365.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
Continuing my "novice interpretation" from before... Tatsuo Ishii-4 wrote > 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 do not believe this to be true from what I've scanned. Inside an "implicit" transaction it will be but in an "explicit" transaction the SYNC does not cause the transaction to close so any named and unnamed portals should still exist after the SYNC (or FLUSH) sequence is completed. This allows for cursors to be maintained over the entire lifetime of the explicit transaction. I do not follow where Tom's FLUSH comment is helpful here. In an explicit transaction their behavior should be semantically identical. In the implicit transaction case the use of FLUSH should not enable you to change the statement that is being executed inside the single-statement-transaction. In the example the error should come at #2 and you'd never get to #3 where you'd issue SYNC/FLUSH (or rather when you get to three you are already dead). SYNC vs. FLUSH in the documentation is confusing as to how they interact with implicit vs. explicit transactions. In the explicit transaction since SYNC issues a FLUSH anyway, the only difference seems to be the presence of the RFQ message. How does this (SQL) sequence work - knowing each COMMAND is a sequence of PARSE-BIND-EXECUTE extended commands that either suceeds or fails: 1) BEGIN; 2) SUCCESSFUL COMMAND; 3) SYNC; 4) ERROR COMMAND; 5) SUCCESSFUL (in theory) COMMAND; 6) SYNC; 7) SUCCESSFUL (in theory) COMMAND; 8) COMMIT; The second SYNC resets and "returns to normal message processing" but the transaction as a whole is in a failure mode. The interesting items are 5 and 7. > So if we are not in an explicit transaction we cannot reuse unnamed portal > because Sync closes the transaction Correct. In an implicit transaction all un-held portals are closed upon SYNC - named or otherwise. Note that the use of "not explicit" instead of "implicit" makes reading this discussion a little more difficult. However, because of: > An unnamed prepared statement lasts only until the next Parse statement > specifying the unnamed statement as destination is issued. the unnamed_statement should still exist. I can see this being useful if you are inserting 10,000 records via the extended protocol and want to "save" every 1,000. After SYNCing the first 1,000 BIND/EXECUTES you can continue using BINDing the original unnamed_statement to execute the next 1,000 and so forth. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Question-regarding-Sync-message-and-unnamed-portal-tp5726023p5770370.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
On Wed, Sep 11, 2013 at 2:06 AM, Bruce Momjian <bruce@momjian.us> wrote:
> 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?
This is right.
AFAIU, purpose of SYNC message as per code for explicit and implicit
transaction is as below:
For Implicit Transaction: It will commit or abort the current
transaction which will internally close all the portals except FOR
HOLD named portals.
For Explicit Transaction:
It will do CommandCounterIncrement() which is required as we have
finished executing a command someplace within a transaction block.
Now I am not able to see how below statement in one of above mails is correct
> 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 think portal will be destroyed by Close 'C' message.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
> 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?
Sorry for confusion. I wanted to say:
> It would be nice if something like "unnamed portal will be destroyed
> by a Sync message if you are in an implicit transaction" is in our
> manual.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp