>
> Hello:
>
> I noticed the locking code in the backend/storage/lmgr directory has had a
> lot of modifications between 6.3.2 vs. 6.4. I know that Vadim is working
> on changing the table-level locking scheme of 6.3.2 towards a
> multi-version concurrency control scheme. I'm wondering how much along
> these modifications are -- it looks like there were changes made to the
> existing locking scheme but no additional features were added. This is
> based on a very cursory look at the locking code in 6.4 (the locking code
> is a lot more complicated than I had initially thought it was going to
> be).
>
> I'm curious as to how the multi-version scheme will be implemented. Vadim
> said that Postgres has a non-overwriting storage manager which can be
> exploited for this concurrency control scheme. I'm not sure I understand
> him -- values that are updated in a table are written to the database in
> such a fashion that the old value remains accessible? This is
> accomplished without a recovery log?
>
> Also, there is some user-level locking code in the contrib directory by
> Massimo that (if I am correct in my understanding of it), seems to be
> providing row-level locking capabilities through query selects. Is this
> something that will be added to the Postgresql core at a future date?
No, this isn't row-level locking, it is a non-blocking mechanism which
can be used by applications to signal that some entities should not be
modified by other users because they are user-locked by one application
instance.
This is totally transparent and orthogonal with respect to standard locks.
--
Massimo Dal Zotto
+----------------------------------------------------------------------+
| Massimo Dal Zotto email: dz@cs.unitn.it |
| Via Marconi, 141 phone: ++39-0461534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: finger dz@tango.cs.unitn.it |
+----------------------------------------------------------------------+