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