Re: Simulating serial fields: locking a row with select for update statement

In article <35EA9535.60F533BE@vlc.centrisa.es>, >We thought to do it using 'select for update' but it seems not to work >because other users can read the old value after the 'select for update' >statement and before the commit. This is exactly our experience. Bug? Feature? Who knows. >Do you know why the select for update statement doesn't lock the row? >Anyone know if there is another way (or the best way) to simulate serial >fields? What I did to fix it is, like someone else suggested: I have another column in that table that's not "used", so I: begin transaction; set isolation to repeatable read; update keys set other_column = some_value where row=myrow; select next_key from keys where row=myrow; update keys set next_key=next_key+1 where row=myrow;commit transaction; Without the third line in there, I was getting dirty reads, and more than one process could get the same key. Now the problem seems to be fixed. -- Asya now hanging at things.org mail addressed to baygate will be discarded unread.