Re: "cancelling statement due to user request error" occurs but the transaction has committed.
От | Robert Haas |
---|---|
Тема | Re: "cancelling statement due to user request error" occurs but the transaction has committed. |
Дата | |
Msg-id | CA+TgmoYutWhVk53__X8Qz_CT2e-Y8qSMbejCFJPvwinZZs++yw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: "cancelling statement due to user request error" occurs but the transaction has committed. (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: "cancelling statement due to user request error" occurs but the transaction has committed.
Re: "cancelling statement due to user request error" occurs but the transaction has committed. |
Список | pgsql-hackers |
On Sun, Jun 8, 2014 at 2:52 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> I think this cancellation request must not interrupt the internal commited >> transaction. >> >> This is because clients may misunderstand "the transaction has >> rollbacked". > > There can be similar observation if the server goes off (power > outage or anything like) after committing transaction, client will > receive connection broken, so he can misunderstand that as well. > I think for such corner cases, client needs to reconfirm his action > results with database before concluding anything. I don't agree with this analysis. If the connection is closed after the client sends a COMMIT and before it gets a response, then the client must indeed be smart enough to figure out whether or not the commit happened. But if the server sends a response, the client should be able to rely on that response being correct. In this case, an ERROR is getting sent but the transaction is getting committed; yuck. I'm not sure whether the fix is right, but this definitely seems like a bug. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: