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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Naoya Anzai <anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Akio Iwaasa <iwaasa(at)mxs(dot)nes(dot)nec(dot)co(dot)jp>
Subject: Re: "cancelling statement due to user request error" occurs but the transaction has committed.
Date: 2014-06-10 14:18:41
Message-ID: 29440.1402409921@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

In general, the only way to avoid that sort of behavior for a post-commit
error would be to PANIC ... and even then, the transaction got committed,
which might not be the expectation of a client that got an error message,
even if it said PANIC. So this whole area is a minefield, and the only
attractive thing we can do is to try to reduce the number of errors that
can get thrown post-commit. We already, for example, do not treat
post-commit file unlink failures as ERROR, though we surely would prefer
to do that.

So from this standpoint, redefining SIGINT as not throwing an error when
we're in post-commit seems like a good idea. I'm not endorsing any
details of the patch here, but the 20000-foot view seems generally sound.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2014-06-10 14:19:30 Re: "cancelling statement due to user request error" occurs but the transaction has committed.
Previous Message Serge Negodyuck 2014-06-10 14:06:49 Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby