| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:45:35 |
| Message-ID: | CA+TgmoZ7=b6sZU2M4Be=r1w-6qAr7BoS3P42pTwysMKQS8mq+w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 10, 2014 at 10:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> ... 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.
>
>> We could treated it as a lost-communication scenario. The appropriate
>> recovery actions from the client's point of view are identical.
>
> I'd hardly rate that as an attractive option.
Well, the only other principled fix I can see is to add a new reponse
along the lines of ERRORBUTITCOMMITTED, which does not seem attractive
either, since all clients will have to be taught to understand it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gurjeet Singh | 2014-06-10 14:45:50 | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
| Previous Message | Tom Lane | 2014-06-10 14:42:42 | Re: "cancelling statement due to user request error" occurs but the transaction has committed. |