Re: More information on how to understand table pg_locks.

"Olivier Ceulemans" <Olivier(dot)Ceulemans(at)irislink(dot)com> 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