Re: commit errors
От | Tom Lane |
---|---|
Тема | Re: commit errors |
Дата | |
Msg-id | 13878.1044282067@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | commit errors (Ryan VanderBijl <rvbijl-pgsql@vanderbijlfamily.com>) |
Список | pgsql-general |
Ryan VanderBijl <rvbijl-pgsql@vanderbijlfamily.com> writes: > Within an application, if I receive an error executing 'BEGIN', > 'ROLLBACK', or 'COMMIT', what should I do? Well, BEGIN when not in a transaction, and ROLLBACK when in one, should pretty much *always* succeed. If they don't, I'd think I'd recommend an application panic --- it's unlikely that any automatic recovery procedure is going to improve the situation. As far as COMMIT goes, you should *definitely* be prepared for failures on commit. A fairly obvious case is commit-time constraint checks (not sure that we have any at the moment, but it'll likely be there someday). Implementation-level problems could also surface (eg, no disk space to write commit record). > Yes, the documentation says I should either get 'COMMIT' back, > or 'WARNING: COMMIT: no transaciton in progress'. However, > what if, for example, the tcp/ip connection drops at that > point? What should my application do? This is the classic catch-22: the backend may or may not have replied COMMIT, but you don't know. If you are concerned about automatic recovery from this situation, you'd better design your application so that you can tell after reconnecting whether your particular transaction committed or not. regards, tom lane
В списке pgsql-general по дате отправления: