Ok, in multi-version systems readers never lock
selected rows and so never block writers. Nice but
cause problems in some cases: if you want
to implement referential integrity at the
application level then you'll have to use
LOCK TABLE IN SHARE MODE or SELECT FOR UPDATE to
prevent updation of primary keys etc. Not so good...
So, what about FOR SHARE LOCK clause in SELECTs?
Like FOR UPDATE clause, FOR SHARE LOCK clause
will lock selected rows, but in _share_ mode.
This is some kind of read-locking on demand.
Disadvantages:
1. FOR SHARE LOCK will use lock manager to lock rows, but lmgr can't handle "too many" locks. (note that UPDATE,
DELETE& SELECT FOR UPDATE use only one entry in lmgr table for ALL updated/marked_for_update rows).
2. UPDATE/DELETE will go slower than now: server will have to exclusively lock (using lmgr) each row being updated,
update/delete it and release lmgr' lock after that (note that currently lmgr locking is not used for rows). On the
otherhand, SELECT FOR SHARE LOCK could mark locked rows in buffer (t_infomask |= HEAP_MARKED_FOR_SHARE) and so
UPDATE/DELETE could acquire lmgr lock only if row is marked...
Comments ?
Vadim
