On May 24, 2007, at 15:57 , Alvaro Herrera wrote:
> A.M. wrote:
>>
>> Indeed. Wouldn't it be a cool feature to persists transaction states
>> across connections so that a new connection could get access to a
>> sub-
>> transaction state? That way, you could make your schema changes and
>> test them with any number of test clients (which designate the state
>> to connect with) and then you would commit when everything works.
>>
>> Unfortunately, the postgresql architecture wouldn't lend itself well
>> to this. Still, it seems like a basic extension of the notion of sub-
>> transactions.
>
> Hmm, doesn't this Just Work with two-phase commit?
2PC requires that the modifications already be in concrete. What I
suggest is a method for a new connection to insert itself into an
existing (sub-)transaction SQL stream, make changes, and commit to
the root or parent transaction.
In the scenario where changes are pending, only one connection can
test the changes- it must be the connection that opened the
transaction. Concurrency issues cannot be tested before committing,
for example.
The implementation could be as simple as decoupling connections from
transactions- then a connection could make serialized requests to
other backends. A proof-of-concept could certainly be cobbled
together with pipes and pl/perl, but the real beef would be the
ability to "pass" responsibility for transactions from one connection
to another.
Cheers,
M