On Tue, Jun 10, 2014 at 10:30:24AM -0400, Robert Haas wrote:
> On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmh...@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.

Did we ever do anything about this?

  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to