Re: commit errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ryan VanderBijl <rvbijl-pgsql(at)vanderbijlfamily(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: commit errors
Date: 2003-02-03 14:21:07
Message-ID: 13878.1044282067@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ryan VanderBijl <rvbijl-pgsql(at)vanderbijlfamily(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2003-02-03 14:30:04 Re: change in behaviour? Is this a regression in function?
Previous Message greg 2003-02-03 14:15:29 Re: DBI driver and transactions