BUG #7529: Support different error handling behavior than auto rollback

From: legoharyanto(at)gmail(dot)com
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #7529: Support different error handling behavior than auto rollback
Date: 2012-09-10 20:22:52
Message-ID: E1TBAVQ-0002tp-S7@wrigleys.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 7529
Logged by: Lego Haryanto
Email address: legoharyanto(at)gmail(dot)com
PostgreSQL version: 9.0.5
Operating system: Any
Description:

I understand that current transaction behavior in PostgreSQL is to throw
away the whole transaction away (rollback) if there's at least one error
within the transaction.

I believe on certain application of data replication, say, migration from
other database source, ... this will be pretty cumbersome to support in
PostgreSQL even though users have some conflict resolution strategy in
mind.

On the following scenario, imagine this transaction is coming from a source
of different DB, migrating into a PostgreSQL target.

BEGIN
INSERT #1... (success)
INSERT #2... (success)
INSERT #3... (error or conflict/collision)
INSERT #4... (success)
COMMIT;

Current behavior of PostgreSQL is that the INSERT #4 command is ignored
because of the error on INSERT #3 (subsequent commands are ignored).

And the COMMIT command is accepted as ROLLBACK, which we can argue it's
misleading because user does an explicit COMMIT, but the actual action is a
rollback.

Can we actually support honoring the successful DMLs above, and do the
actual COMMIT that is inserting #1, #2, and #4 in above example?

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message mwtoews 2012-09-10 20:40:12 BUG #7530: initdb.exe ignores --locale option, uses "English_United States.1252"
Previous Message Tom Lane 2012-09-10 16:09:33 Re: BUG #7528: Spurious empty log file created