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!"
