Tom Lane <t...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
