I have this problem:
user1 executes an update or delete with transaction for
10/20 seconds in a rekord with pk 1. Why in this time other
user(user2) makes a select on that rekord reads uncommited
data? I want that user2 reads commited data!! I tried with
isolation SERIALIZABLE, but I have self result! If user2
deletes or updates that rekord the transaction works and
waits commit of user1.

Sorry for my weak english.

Bye and tnks!

Aragorn <alphacentauri2 (AT) fuckspamlibero (DOT) it> wrote:
You cannot see uncommitted data in PostgreSQL from another transaction.

When transaction 1 has updated a record and not yet committed it,
transaction 2 will NOT see the uncommitted change, but the previous,
COMMITTED version of the record.

The change of transaction 1 will not be visible to transaction 2 before
transaction 1 commits.

The matter gets more complicated when transaction 2 wants to change the
record. A change can only take place in the most recent version of the
record, so transaction 2 will have to wait until transaction 1 commits
or rolls back and thereby releases the lock it holds on the row.

Are you used to database systems that handle this differently, like DB2?
Or is this the first time you try to understand transactions?

Yours,
Laurenz Albe

Laurenz Albe ha scritto:


Sorry,I'm wrong word! I wanted say previous data.
When I make a SELECT on data, if there is a transaction on it, how I
can know that data is
in state of modification from an other user or to make execute the
SELECT after that the transaction of the other is ended ?

Tnks bye!

gigarimini (AT) gmail (DOT) com wrote:

LOCK TABLE foo IN ACCESS EXCLUSIVE MODE

from inside of your transaction to achieve that.

Christoph

--

perl -e "print scalar reverse q/ed.enilno (AT) ergn (DOT) l.hc/"

Ch Lamprecht <christoph.lamprecht.no.spam (AT) web (DOT) de> wrote:
Yes, but that's a pretty brutal measure...

I would recommend to thing about your requirements:
WHY is it so bad for you to get the old version of the row?
Depending on the reason, I can maybe suggest alternative approaches to
solve your problem.

You can always make sure that nobody is modifying the row you are reading
with

SELECT ... FOR UPDATE

Yours,
Laurenz Albe

Laurenz Albe wrote:

Thanks you for help!!


Bye!