"Olivier Ceulemans" <Olivier.Ceulemans@xxxxxxxxxxxx> writes: > I'm running 'PostgreSQL 8.2.0 on i686pc-mingw32, compiled by GCC gcc.exe > (GCC) 3.4.2 (mingw-special)'. BTW: you oughta think about an update to 8.2.3; we've fixed several nasty bugs, most especially in the windows port. > Transaction B is simply blocked by transaction A at step 4. Right, because A has a share lock on the row that B wants to update. This is to ensure that nobody deletes that row or changes its key value before A's new row is committed and visible. (Until that happens, a would-be deleter would see no reason he couldn't do it.) > Now I understand what happen. > Now I'm worried it doesn't happen on other rdbms. :-) There's been some discussion of trying to lock only the key columns, ie, allow updates that just change non-key columns. It's not at all clear how to do that within Postgres though. The other systems you tried probably have different approaches to this problem. regards, tom lane
