Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Throwing an error on commit of a transaction when its work has
actually been persisted seems as bad as failing to persist the work
of a transaction when the commit appears successful. If we know we
have met the persistence guarantees and some problem occurs after
that, then it seems to me we should issue a warning and indicate
success. If we don't know whether the work will be persisted, it
seems to me we can block until we find out (if that's feasible) or
break the connection without indicating one way or the other. The
work of the transaction must either all be persisted or not (I'm
assuming this isn't a problem here), and any user must be prepared
to deal with a broken connection before response on a commit
attempt.
I don't know whether changing all failures beyond the persistence
point in a commit to warnings is sufficient, but I think it is
required for anything which doesn't break the connection.
-Kevin
