Re: PREPARE and transactions - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: PREPARE and transactions
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB34101AE8C@Herge.rcsinc.local
Whole thread Raw
In response to PREPARE and transactions  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Responses Re: PREPARE and transactions  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List pgsql-hackers
> > I would be fine with changing the lifetime if an EXECUTE failure did
not
> > abort the current transaction.  Then I could simply watch the return
> > code of the statement execution and prepare the statement on
> > demand...from my point of view, this would actually be the most
elegant
> > scenario.
>
> BEGIN;
>     ... do something ... ;
>     SUBBEGIN;
>         EXECUTE ...;
>         -- if it fails:
>         -- SUBABORT;
>         -- PREPARE ...;
>         -- SUBBEGIN;
>         -- EXECUTE ...;
>         -- can continue as if nothing happened
>     SUBCOMMIT;
> COMMIT;

This is not an option: this requires that every EXECUTE be wrapped with
a subtransaction.  This is a performance killer because it (at minimum)
triples my statement turnaround latency.

With the current behavior, you can guarantee certain behaviors by
wrapping PREPARE/DEALLOCATE... and I was eagerly anticipating your work
to do this.  I would much rather do that than be required to wrap every
single EXECUTE (recall that most of my I/O goes through prepared
statements).

Merlin


pgsql-hackers by date:

Previous
From: Dennis Bjorklund
Date:
Subject: Re: [PATCHES] nested xacts and phantom Xids
Next
From: "Thomas Hallgren"
Date:
Subject: Re: warning missing