"Olivier Ceulemans" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
