Allow nested transactions
От | Haroldo Stenger |
---|---|
Тема | Allow nested transactions |
Дата | |
Msg-id | 39498244.A0DE2836@adinet.com.uy обсуждение исходный текст |
Список | pgsql-hackers |
Hello all, As you know, PostgreSQL handles in a restricted way a transaction, falling in *ABORT STATE*, when a statement which yields error is entered. Not only the transaction isn't allowed to continue processing statements, until a finishing statement is entered, but also the whole transaction is ROLLedBACK, regardless of which statement finished the transaction (ABORT, ROLLBACK, COMMIT, END). I'm needing as water the ability of PostgreSQL to continue working normally after an error within a transaction, and not to fall in *ABORT STATE*. Many of you already read my previous messages about this topic, and maybe my insistence is becoming upsetting. I apologize. I'm willing to do it myself. But my lack of knowledge about many required topics, leaves my chances low. So I'm following alternative paths, as to try to persuade others of the importance of this issue. In the TODO list, we can read: > EXOTIC FEATURES > > * Add sql3 recursive unions > * Add the concept of dataspaces > * Add replication of distributed databases > * Allow queries across multiple databases > * Allow nested transactions (Vadim) From this, I understand that: 1) The development group found that the behaviour change proposed above, will be achieved, by encapsulating offending statements within inner transactions, so that outer ones remain OK, and can follow to process statements, until COMMIT; not by changing such behaviour directly. I haven't found in the TODO list, other related items. 2) The priority assigned to this issue is sort of low, since it's below EXOTIC FEATURES, and is in the last in the list. Making transactions nestable, will surely become a great feature, compared to competitor databases. And Vadim seems to be the only one able to cope with it, and he has to do lots of things before this one. I wonder if by focusing narrowerly at the desired behaviour change (not to fall in ABORT STATE), we could achieve sooner one of the two goals. I'm using JDBC to communicate with the backend. If nesting transactions were the solution, I wonder if by enclosing <*automatically within the driver*> each statement inside a nested transaction, would appear to the frontend app, as if PostgreSQL handled offending statements within transactions in a smooth way. Of course this wouldn't be a general solution, so, maybe creating a "SET ENCLOSE_EVERY_POSSIBLE_OFFENDING_STATEMENT [ON|OFF]" backend statement, we could achieve the desired behaviour change. As you can see, I have some ideas, I have needs, I'm poorly trying to solve the problem, and I want all of you to discuss about this. I have found that my worrying about this, is shared by some PostgreSQL users, i.e., when trying to insert a record, in case it didn't exist previously, and update it, in case it exists, problem which has been discussed a lot lately, in the GENERAL list. Many of you have already helped me in a way or another in this issue, including but not limited to Peter Eisentrout, and Ed Loehr. Special thanks to you. What do you think? Best Regards, Haroldo Senger.
В списке pgsql-hackers по дате отправления: