I was wondering whether there could be an atomic commit;begin command
for postgresql, in order to open up a transaction at the beginning of
a unit of work in a client session, so that client applications don't
have to duplicate work with having optimistic locking and version id
fields in their tabl
t 14 1:56 , "Trevor Talbot" sent:
>On 10/13/07, syan tan > wrote:
>> I was wondering whether there could be an atomic commit;begin command
>> for postgresql, in order to open up a transaction at the beginning of
>> a unit of work in a client session, so that cl
On Sun Oct 14 7:41 , "Trevor Talbot" sent:
>On 10/14/07, Syan Tan wrote:
>> I meant commit and continue current transaction. The transaction is opened
>> on the user application caching composite data from many tables regarding
>> a root object. Because alm
; command, then
you could avoid that extra work in clients - or maybe warping transactions
for this purpose makes it more difficult to write transactions for
the usual batch processing purposes.
On Mon Oct 15 5:28 , "Trevor Talbot" sent:
>On 10/15/07, Syan Tan wrote:
>
>&
On Mon Oct 15 5:28 , "Trevor Talbot" sent:
>The only difference is in the data you _can_ read. For the
>SERIALIZABLE isolation level, that data was decided at the beginning
>of the transaction. A row that was updated by another transaction
>will make the version that you can see effectively
n level in postgres.
google found my reference, and the reference mentioned it was
different from serializable.
On Mon Oct 15 9:09 , "Trevor Talbot" sent:
>On 10/15/07, Syan Tan wrote:
>
>> >Also keep in mind that MVCC is not the only way to implement
>> >transa
