Re: "cancelling statement due to user request error" occurs but the transaction has committed.

Поиск
Список
Период
Сортировка
Искать
От
Amit Kapila
Тема
Re: "cancelling statement due to user request error" occurs but the transaction has committed.
Дата
Msg-id
CAA4eK1L7xA1CgscQTSq9v3GBmW3cyQhiUerSdDr08o8EXoRyqA@mail.gmail.com
Ответ на
Список
Дерево обсуждения
"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. Amit Kapila <amit.kapila16@gmail.com>
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>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Kevin Grittner <kgrittn@ymail.com>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Tom Lane <tgl@sss.pgh.pa.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Robert Haas <robertmhaas@gmail.com>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Bruce Momjian <bruce@momjian.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Bruce Momjian <bruce@momjian.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Robert Haas <robertmhaas@gmail.com>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Bruce Momjian <bruce@momjian.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Robert Haas <robertmhaas@gmail.com>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Alvaro Herrera <alvherre@2ndquadrant.com>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Bruce Momjian <bruce@momjian.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Tom Lane <tgl@sss.pgh.pa.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Bruce Momjian <bruce@momjian.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Bruce Momjian <bruce@momjian.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Tom Lane <tgl@sss.pgh.pa.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Bruce Momjian <bruce@momjian.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Tom Lane <tgl@sss.pgh.pa.us>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Robert Haas <robertmhaas@gmail.com>
Re: "cancelling statement due to user request error" occurs but the transaction has committed. Naoya Anzai <anzai-naoya@mxu.nes.nec.co.jp>
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 по дате отправления
От: Amit Kapila
Дата:
От: Amit Kapila
Дата:
Сообщение: Re: Proposing pg_hibernate
FAQ