On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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.
We could treated it as a lost-communication scenario. The appropriate
recovery actions from the client's point of view are identical.
> 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.
Cool, that makes sense to me also.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company