Re: PREPARE and transactions

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: <pgsql-hackers(at)postgresql(dot)org>, "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
Subject: Re: PREPARE and transactions
Date: 2004-06-26 13:12:33
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB34101AE8C@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Hallgren 2004-06-26 14:20:37 Re: warning missing
Previous Message Dennis Bjorklund 2004-06-26 05:26:38 Re: [PATCHES] nested xacts and phantom Xids