Re: "cancelling statement due to user request error" occurs but the transaction has committed.
От | Robert Haas |
---|---|
Тема | Re: "cancelling statement due to user request error" occurs but the transaction has committed. |
Дата | |
Msg-id | CA+TgmoZ7=b6sZU2M4Be=r1w-6qAr7BoS3P42pTwysMKQS8mq+w@mail.gmail.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.
|
Список | pgsql-hackers |
On Tue, Jun 10, 2014 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: