Re: BUG #7529: Support different error handling behavior than auto rollback
От | Pavel Stehule |
---|---|
Тема | Re: BUG #7529: Support different error handling behavior than auto rollback |
Дата | |
Msg-id | CAFj8pRB7HCwNL-wwwM6WuRqPB4wUKD8T-HGkMp-Xn25pwVOL5g@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #7529: Support different error handling behavior than auto rollback (legoharyanto@gmail.com) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: