Re: Does error within transaction imply restarting it?
От | Ross J. Reedstrom |
---|---|
Тема | Re: Does error within transaction imply restarting it? |
Дата | |
Msg-id | 20000425112955.A13028@rice.edu обсуждение исходный текст |
Ответ на | Re: Does error within transaction imply restarting it? (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-general |
Peter and Harold (and all): I just tried this with current CVS sources. While it _does_ allow one to continue after SQL syntax errors, and 'relation not found' type errors, it makes a mess if the error is caused by a constraint firing, such as a unique column constraint. I ended up with the dead tuple going live, with a duplicate field, after some NOTICES about buffer leaks. 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 On Sat, Apr 15, 2000 at 08:52:02PM +0200, Peter Eisentraut wrote: > Haroldo Stenger writes: > > > I seems that other DBMSs, don't care about erroneous statements within > > a transaction. Now, I have several paths to follow: 1) Hacking the > > backend ;-) > > If you're really brave you can try this change in > backend/tcop/postgres.c: > > if (sigsetjmp(Warn_restart, 1) != 0) > { > time(&tim); > > if (Verbose) > TPRINTF(TRACE_VERBOSE, "AbortCurrentTransaction"); > > - AbortCurrentTransaction(); > InError = false; > if (ExitAfterAbort) > { > ProcReleaseLocks(); /* Just to be sure... */ > proc_exit(0); > } > } > > Absolutely no guarantee, there's probably more to it. Hmm, I wonder, maybe > not. > > > How can I motivate key developers to make their way into an action > > plan? > > Becoming one yourself or throwing large amounts of cash at the existing > ones. :) Trying the above and tracing down any arising problems might be a > start though. >
В списке pgsql-general по дате отправления: