Skip site navigation (1) Skip section navigation (2)

Transaction Abort State?

From: "Warren W(dot) Gay VE3WWG" <ve3wwg(at)cogeco(dot)ca>
To: PostgreSQL mailing list <pgsql-interfaces(at)postgresql(dot)org>
Subject: Transaction Abort State?
Date: 2002-08-17 04:56:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
Question: In PostgreSQL it seems that if I perform a series of operations
in a transaction, everything goes peachy until I try to INSERT a row
that results in a duplicate key error.

The application then recovers from this particular error (anticipating the
possibility for it), and then continues the transaction. Unfortunately, the
PostgreSQL server (at least with libpq) reports that it is now in an
"abort state".. forcing ultimately the application to ROLLBACK and
start all over again.  Ugh -- very painful.

Is this intended behavior?

In INFORMIX for example, the server keeps trucking until you
choose COMMIT or ROLLBACK. These operations of course only
work on the successful operations so far, but failed operations like
INSERTs are tolerated (ie. ignored).

The current PG behaviour forces the application to test for duplicate
insert problems first by performing a SELECT operation. This is
extra and unnecessary overhead, if the failed INSERTs did not
toss away the pending transaction.

I have used a specific example, of a larger issue.  That being why
does the server have to enter "abort state", when failed portions
of the transaction can be ignored -- leaving the final decision
up to the application at the COMMIT/ROLLBACK point? I know
for a fact that INFORMIX works this way, and it is very
successfully exploited by applications.

Maybe this is just a libpq issue?

Using PostgreSQL 7.2.1 under FreeBSD 4.4/i386, on Pentium-III.

Thanks, Warren.

Warren W. Gay VE3WWG

pgsql-interfaces by date

Next:From: Bruce MomjianDate: 2002-08-17 12:19:35
Subject: Re: [INTERFACES] libpgtcl modifications
Previous:From: Warren W. Gay VE3WWGDate: 2002-08-17 04:46:13
Subject: Re: determining if there's a transaction in progress

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group