On Sun, Jun 8, 2014 at 2:52 AM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
