From: Warren W. Gay VE3WWG <ve3wwg@cogeco.ca>
To: PostgreSQL mailing list <pgsql-interfaces@postgresql.org>
Subject: Transaction Abort State?
Date: Sat, 17 Aug 2002 00:56:31 -0400
Message-ID: <3D5DD77F.5080501@cogeco.ca> (raw)
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
http://home.cogeco.ca/~ve3wwg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: ve3wwg@cogeco.ca
Subject: Re: Transaction Abort State?
In-Reply-To: <3D5DD77F.5080501@cogeco.ca>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox