On Fri, May 28, 2004 at 01:43:16PM -0400, Bruce Momjian wrote: > In this case, I want to try all of the inserts, but any of them can > fail, then I want the bottom part done.
I wonder where everyone eas when I asked this question a lot of time ago. I said I thought the behavior should be like I described, and no one objected. Personally I think it would be a mistake to allow the COMMIT for the subtransaction to ignore the fact that the subxact was aborted. However I realize what you are proposing, and maybe this can be implemented using a parameter to COMMIT (indicating to not propagate the error if it's in aborted state, but commit normally otherwise). However if everyone disagrees, I can take that part out, and the code would be simpler. IMHO however, it would be less reliable. > In my logic, the subtransaction COMMIT is part of the subtransaction and > should not affect the outer transaction's state. In some cases yes, but not all. In others, the outer transaction could trust that the inner one worked; to make the example you posted work, I'd use a program rather than a script, and check the return values (or the transaction state). If the subxact is in aborted state, issue ROLLBACK and try again; if not, commit. > Unfortunately, we don't have any similar behavior in our 7.4 code > because whether you issue COMMIT or ABORT, it does not affect the outer > session. Of course. This is new functionality. > Right now I think just posting examples will work fine. I think the > above case shows we are not ready for documentation yet. What I would > like is for folks to focus on testing so we can find any open issues > like this one and address them. Ok. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth. That's because in Europe they call me by name, and in the US by value!" ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html