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

The following bug has been logged on the website:

Bug reference:      7529
Logged by:          Lego Haryanto
Email address:      legoharyanto@gmail.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?

Hello

this is not bug - please, can you send your proposal to pg_hackers mailing list?

Regards

Pavel Stehule

2012/9/10  <legoharyanto@gmail.com>:
> The following bug has been logged on the website:
>
> Bug reference:      7529
> Logged by:          Lego Haryanto
> Email address:      legoharyanto@gmail.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?
>
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs