Alvaro Herrera wrote:
> 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.
Sorry, I didn't understand the question at the time, or wasn't paying
attention.
> 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.
Imagine this case used in a script:
BEGIN;DROP TABLE test;CREATE TABLE test(x int);COMMIT;
This will not work because the drop might fail. However you could use this:
BEGIN;BEGIN;DROP TABLE test;COMMIT;CREATE TABLE test(x int);COMMIT;
It is done in a transaction so the table replace is an atomic operation.
One interesting idea would be for COMMIT to affect the outer
transaction, and END not affect the outer transaction. Of course that
kills the logic that COMMIT and END are the same, but it is an
interesting idea, and doesn't affect backward compatibility because
END/COMMIT behave the same in non-nested transactions.
If this is the type of issue we are dealing with for the patch, I feel
very good. Good job Alvaro.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
