Thread: Now PostgreSQL recovers from errors within trns
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
-----------------------------------------------
hstenger@adinet.com.uy writes:
> My goal is to make the backend accept erroneous commands, not falling
> in *ABORT STATE*, but rolling back automatically, & continue accepting
> commands.
The way you're doing it, you might as well just not use transaction
blocks at all. I don't think wiping out the effects of all preceding
commands within the transaction counts as "recovering from an error".
regards, tom lane
Tom Lane wrote: > > hstenger@adinet.com.uy writes: > > My goal is to make the backend accept erroneous commands, not falling > > in *ABORT STATE*, but rolling back automatically, & continue accepting > > commands. > > The way you're doing it, you might as well just not use transaction > blocks at all. I don't think wiping out the effects of all preceding > commands within the transaction counts as "recovering from an error". Ok, maybe I exagerated, but kind of solves my problem. GeneXus, my CASE tool, will send begin/commit pairs, so I must 'recover' automatically. I aimed DB2-like behaviour, which I was told, aborts on errors within transactions, but remains in a runnable state. Don't you consider it valueable whatsoever? Haroldo. -- ----------------------+------------------------Haroldo Stenger | hstenger@ieee.orgMontevideo, Uruguay. | hstenger@adinet.com.uy ----------------------+------------------------Visit UYLUG Web Site: http://www.linux.org.uy -----------------------------------------------
At 02:10 PM 7/31/00 -0300, hstenger@adinet.com.uy wrote: >Tom Lane wrote: >> >> hstenger@adinet.com.uy writes: >> > My goal is to make the backend accept erroneous commands, not falling >> > in *ABORT STATE*, but rolling back automatically, & continue accepting >> > commands. >> >> The way you're doing it, you might as well just not use transaction >> blocks at all. I don't think wiping out the effects of all preceding >> commands within the transaction counts as "recovering from an error". > >Ok, maybe I exagerated, but kind of solves my problem. GeneXus, my CASE tool, >will send begin/commit pairs, so I must 'recover' automatically. I aimed >DB2-like behaviour, which I was told, aborts on errors within transactions, but >remains in a runnable state. Don't you consider it valueable whatsoever? Well, Postgresql's behavior isn't SQL92 compliant, but neither is the behavior you want. I far prefer the current non-standard behavior. Eventually, of course, PG should conform to SQL92. GeneXus should be catching the error and issuing a rollback if that's the behavior it expects. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
Don Baccus wrote: > Well, Postgresql's behavior isn't SQL92 compliant, but neither is the > behavior you want. I far prefer the current non-standard behavior. > Eventually, > of course, PG should conform to SQL92. This change is not a must. Is very optional. Since I solved a problem, I'happy. I don't know much about the standards, but agree with you just in case. > GeneXus should be catching the error and issuing a rollback if that's > the behavior it expects. Yup, but GeneXus is closed source, and PostgreSQL is open source. I'm trying to convince GeneXus' ARTech (www.genexus.com.uy) about the importance of supporting PostgreSQL. From the PostgreSQL point of view, if this has place someday, PostgreSQL will gain a lot of corporate users, and a whole new consulting field will be available. Do you understand my point? -- ----------------------+------------------------Haroldo Stenger | hstenger@ieee.orgMontevideo, Uruguay. | hstenger@adinet.com.uy ----------------------+------------------------Visit UYLUG Web Site: http://www.linux.org.uy -----------------------------------------------
On Mon, Jul 31, 2000 at 02:30:40PM -0300, hstenger@adinet.com.uy wrote: > > Yup, but GeneXus is closed source, and PostgreSQL is open source. I'm trying to > convince GeneXus' ARTech (www.genexus.com.uy) about the importance of supporting > PostgreSQL. From the PostgreSQL point of view, if this has place someday, > PostgreSQL will gain a lot of corporate users, and a whole new consulting field > will be available. Do you understand my point? > As an aside, to the hackers (and Ned Lilly, in particular) This sort of corporate evangalism is one avenue in which I could see BreatBridge being very helpful to the PostgreSQL community. Find out what SQL CASE/CAD what-have-you tools are in use in businesses out there, and work with the tool makers to support PostgreSQL out-of-the-box. Existing end users (and potential end users) need to make noise too, of course, but GreateBridge would be in the position to credibly tell the tool builders how much effort it might be to support pgsql. Heck, for the lower end of these tools, they could package pgsql with the tool, to provide a working, functional system, with an "upgrade" path to commericial systems. A lot of those systems would just never find the need top upgrade, would be my bet. Hmm, a quick survey over on GENERAL might get a starter list of tools to target. Myself, I've looked at Embarcadero Technology's "lifecycle" tools: ER/Studio FastSQL, DBArtisan. They look interesting, and sort of work with the ODBC driver, but could use some tweaking to unserstand a pgsql installion better. http://www.embarcadero.com/ Another, not quite the same category, but interesting, one is a replication/remote access layer we looked at about a year ago: ISG Navigator. Hmm, seems to have been renamed to AttunityConnect. That one was very flexible: could be tuned by editing a config file with various 'features' flags. http://www.attunity.com/ Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005