Now PostgreSQL recovers from errors within trns
От | hstenger@adinet.com.uy |
---|---|
Тема | Now PostgreSQL recovers from errors within trns |
Дата | |
Msg-id | 39858929.59012BAC@adinet.com.uy обсуждение исходный текст |
Ответы |
Re: Now PostgreSQL recovers from errors within trns
|
Список | pgsql-hackers |
Hello nice people, Slowly & happily I'm becoming a PostgreSQL hacker ;-) What a pleasure. Last days, I learned to use the debugger, to follow code, & understood some of PostgreSQL internals. In spanish we say someone is a 'cabeza dura' when tries hard to do something against the odds, & so am I. My goal is to make the backend accept erroneous commands, not falling in *ABORT STATE*, but rolling back automatically, & continue accepting commands. So I found that there is a function StartTransactionCommand(), which does things before executing commands, depending on transaction state. And it did nothing explicitely when TBLOCK_ABORT. So I added three lines, which pretend to set the backend in a safe state, and I think I did it. What do you think about this? In my early tests, it works. It complains saying something about the transaction state, but works anyway. I think that by polishing it, the complain can be eliminated. case TBLOCK_ABORT: + s->blockState = TBLOCK_INPROGRESS; + AbortTransaction(); + StartTransaction(); break; So now I can give back to PostgreSQL a 0.1% of what it gave to me. Thanks. Cheers, Haroldo. P.S. Now I'll have to learn java, to make the JDBC give errors analogous to Informix, so that my CASE tool thinks it talks to Informix. Someone posted something about more analyzable error messages by PostgreSQL, maybe we can chat about it. -- ----------------------+------------------------Haroldo Stenger | hstenger@ieee.orgMontevideo, Uruguay. | hstenger@adinet.com.uy ----------------------+------------------------Visit UYLUG Web Site: http://www.linux.org.uy -----------------------------------------------
В списке pgsql-hackers по дате отправления: