Re: Odd query execution behavior with extended protocol
От | Robert Haas |
---|---|
Тема | Re: Odd query execution behavior with extended protocol |
Дата | |
Msg-id | CA+TgmoauDvQDcqJ0TkjKi3qDcVveq5eJqYTi+5=z3H9MC-f8vg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Odd query execution behavior with extended protocol (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Odd query execution behavior with extended protocol
|
Список | pgsql-hackers |
On Tue, Oct 6, 2015 at 5:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> From looking at the code, it appears to me that if the Execute is run >> to completion, then its results will be seen by future statements, but >> if the portal is closed earlier, then not. See the end of >> exec_execute_message. The handler for the Close message (inside >> PostgresMain) doesn't seem to do anything that would result in a >> CommandCounterIncrement() or CommitTransactionCommand(). > >> This does seem a little strange. > > I dunno, if you close a portal before you've gotten CommandComplete, > should you expect that all its actions were taken? Arguably, that > should be more like a ROLLBACK. I dunno either, but a rollback would undo everything, and a commit would do everything. Ending up in a state where we've done some of it but not all of it is strange. Being able to run an unbounded number of commands without a CommandCounterIncrement is *really* strange. I'm not very sure what to do about it, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: