Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Oct 23, 2011 at 6:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> BTW, it strikes me that if we want to do something about that, it ought
>> to be possible; but it has to be built into error handling, not a
>> localized hack for sync rep.
> I actually think that emitting a NOTICE or WARNING and then slamming
> the connection shut is quite elegant,
No, it's a horrid crock, whose only saving grace is that it was
implementable with two or three lines localized to SyncRepWaitForLSN
... or at least, we thought that until Fujii-san started pointing out
the bugs in it. It's not convenient for clients at all, it does not fit
well into the backend structure (which is the reason for the bugs), and
it forces session termination unnecessarily, or at least it would if
we'd been consistent and applied the method to query-cancel as well.
> as it seems to me that any
> client that is paranoid enough to care about sync rep had better
> already be handling the case of a connection loss during commit.
Agreed, but that is a problem that by definition we can't help with.
Also, the issue with connection loss is that you really can't know
whether your transaction got committed without reconnecting and looking
for evidence. There is no reason at all to inject such uncertainty
into the cancel-SyncRepWaitForLSN case. We know the transaction got
committed, and there's no reason to make the client guess about that,
nor to make it parse WARNING messages for which we didn't even get the
assignment of a unique SQLSTATE right (thus making the problem
insoluble anyhow).
> But I think that throwing an ERROR is likely to cause a LOT of client
> breakage, even if you have some special (human-invisible?) flag that
> indicates that you don't really mean it. If we must do something
> other than simulating a server disconnect, letting the command
> completion message go through and annotating it with a NOTICE or
> WARNING seems preferable.
I think you're thinking narrowly of the SyncRepWaitForLSN case. What
I'm trying to point out is that there's a boatload of post-commit code
which is capable of sometimes throwing errors, and that's not ever
going to go away completely.
It might be that it'd work to deal with this by reducing the reported
strength of all such cases from ERROR to WARNING. Not sure that that's
a good idea, but it might work.
regards, tom lane