Skip site navigation (1) Skip section navigation (2)

Re: [Re] Re: PREPARE and transactions

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Re] Re: PREPARE and transactions
Date: 2004-06-25 12:54:57
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB34101AE87@Herge.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-hackers
Jeroen wrote:
> Granted, that's probably going to force the issue.  I do wonder
though:
> one of the arguments in favour of the current semantics is that the
> problems can be worked around using nested transactions.  Then what
were
> people doing before nested transactions, in Tom's scenario where the
> programmer doesn't know where transactions begin?

The trick is that with the current semantics, you don't have to watch
transaction activity, just the prepare statements.  You know if and when
(from the client/driver's point of view) a prepared statement exists
because you created it and don't have to be concerned about the
lifetime.

If you guys change the lifetime, it becomes difficult or impossible to
set a flag on the client which guarantees prepared statement existence.
This means I have to wrap the statement execution with a subtransaction
or run the risk of bouncing a current transaction.  Currently in the
applications I write 70% of all I/O goes through prepared
statements...the reason to do this was to reduce statement turnaround
latency, which is the main driving performance factor in COBOL
applications.

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.

Merlin

Responses

pgsql-hackers by date

Next:From: Jeroen T. VermeulenDate: 2004-06-25 13:25:58
Subject: Re: PREPARE and transactions
Previous:From: Jeroen T. VermeulenDate: 2004-06-25 12:18:46
Subject: Re: [Re] Re: PREPARE and transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group