> 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.
> 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 other hand,
> 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...
If one did not specify FOR SHARE LOCK then the performance would be
similar to the current performance? Then if you want to use the feature,
you pay the performance penalty. Or do you think that the checking
should/will happen irrespective of any query settings?
Also, my commercial Ingres system would escalate row-level locks to
page- and table-level locks when the number of row-level locks exceeded
a (settable) threshold. That seems like a nice compromise between
features and performance, but it can lead to deadlock during the lock
escalation...
- Tom
