| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | peter(dot)garner(at)toward(dot)com |
| Cc: | pgsql-interfaces(at)postgreSQL(dot)org |
| Subject: | Re: [INTERFACES] aborted transactions |
| Date: | 1998-10-26 01:22:09 |
| Message-ID: | 6873.909364929@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-interfaces |
"Peter Garner" <peter(dot)garner(at)toward(dot)com> writes:
> However, it seems to me that if certain
> queries fail, the current transaction is aborted and all
> queries are ignored until the transaction is ended, either
> via commit or rollback.
*Any* backend-detected "fatal" error causes the transaction to
be aborted. I've kinda wished that transactions (atomic update)
could be separated from error-abort also, but right now the two
always go together in Postgres.
> Also if there is no begin
> transaction block, I assume that each statement is a unit
> of work and that all subsequent queries will work.
Right: a statement appearing outside any begin-transaction block
is treated as a self-contained transaction.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter T Mount | 1998-10-26 06:54:23 | Re: [INTERFACES] large object error |
| Previous Message | Peter Garner | 1998-10-26 01:00:32 | large object error |