Re: PostgreSQL transaction locking problem

>I actually thought that he's complaining about the fact that it gives him
>the same id twice if he runs it in two transactions rather than
>the delay until the first commits.
yes that is the problem.

>As written, he gets a delay (because of the LOCK) *and* duplicate IDs
>(because with the serializable isolation level, the second xact can't
i get the same error whether using "read commited" or "serializable".

>see the row inserted by the first, even after waiting for it to commit).
>Worst of both worlds.
>There's a reason why we provide sequences as primitive objects: you
>can't build an equivalent behavior very easily under MVCC rules.
first the case of my example is just that, an example. i want to learn to
use transactions and locking so that i can do the following....

1. run multiple processes in different transactions,
2. executing the same pg/sql functions which,
3. need to read data at the beginning of the function that is committed,
4. perform calculations and write a result.
5. thus competing processes will need to wait for each to commit the result
in turn.

If I could figure this out the code in my first posting would work. Or even
if I could
get the transaction to bail with a transaction error of some sort, but
waiting would be best.

You say it cannot be done easily, but can it be done? This seems like an
essential feature
of locking to me.

Jeff

Jeff Martin
704 Torrey Lane, Apartment D
Boalsburg, PA 16827
H814-466-7791
jeff(at)dgjc(dot)org <mailto:jeff(at)dgjc(dot)org>
www.dgjc.org <http://www.dgjc.org>