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: http://www.postgresql.org/mailpref/pgsql-hackers
