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
