Re: Nested xacts: looking for testers and review - Mailing list pgsql-hackers

This may be out of scope but I'm goign to mention it. Would error trapping
help any of these issues. In Oracle PL/SQL you have an exception section to
handle any known or unknown errors.  Is this for the future or does the
nested xacts code include this at all?


|---------+---------------------------------->
|         |           Bruce Momjian          |
|         |           <pgman@candle.pha.pa.us|
|         |           >                      |
|         |           Sent by:               |
|         |           pgsql-hackers-owner@pos|
|         |           tgresql.org            |
|         |                                  |
|         |                                  |
|         |           05/28/2004 03:05 PM    |
|         |                                  |
|---------+---------------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
     | |       To:       Alvaro Herrera <alvherre@dcc.uchile.cl>
             | |       cc:       Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgresql.org
                     | |       Subject:  Re: [HACKERS] Nested xacts: looking for testers and review
                             |
>------------------------------------------------------------------------------------------------------------------------------|




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,
Pennsylvania
19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
              http://archives.postgresql.org






*************************************************************************
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may
containproprietary, confidential and/or privileged information.  If you are not the intended recipient, any use,
copying,disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient,
pleasenotify the sender immediately by return e-mail, delete this communication and destroy all copies.
 
*************************************************************************