Re: "cancelling statement due to user request error" occurs but the transaction has committed. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: "cancelling statement due to user request error" occurs but the transaction has committed.
Date
Msg-id CAA4eK1L7xA1CgscQTSq9v3GBmW3cyQhiUerSdDr08o8EXoRyqA@mail.gmail.com
Whole thread Raw
In response to "cancelling statement due to user request error" occurs but the transaction has committed.  (Naoya Anzai <anzai-naoya@mxu.nes.nec.co.jp>)
Responses Re: "cancelling statement due to user request error" occurs but the transaction has committed.  (Naoya Anzai <anzai-naoya@mxu.nes.nec.co.jp>)
Re: "cancelling statement due to user request error" occurs but the transaction has committed.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Jun 6, 2014 at 2:11 PM, Naoya Anzai <anzai-naoya@mxu.nes.nec.co.jp> wrote:
>
> Hi All,
>
> When log_duration is true ( or log_min_duration_statement>=0 ),
> If a transaction has internally been commited receives a SIGINT signal
> then a query cancellation error is output.
>
> For example,
> 1. A query like a TRUNCATE is removing bigger table files.
> 2. The session receives SIGINT signal.
> 3. Query cancellation error occurs.
> 4. But the query has commited.
>
>
> naoya=# truncate hoge;
> Cancel request sent
> ERROR:  canceling statement due to user request
> naoya=# select count(*) from hoge;
>  count
> -------
>      0
> (1 row)
> ---
>
> This is because  ProcessInterrupts function is called by errfinish ( in query-duration ereport).
>
> 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.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: avoiding tuple copying in btree index builds
Next
From: Amit Kapila
Date:
Subject: Re: Proposing pg_hibernate