"Thomas G. Lockhart" wrote:
>
> > 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, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes, if FOR SHARE LOCK will mark locked row in buffer
(and so - force buffer write)...
> 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...
As you can see in old lock.c postgres supposed to do
row --> table lock escalation if #rows locked in
table equal 10 - very simple and bad -:)
I wouldn't like to care about # of SHARE LOCKed rows,
at least in 6.5. Actually, this number shouldn't be
too big. In the case of referential integrity, FOR SHARE LOCK
should be used only on primary table and only if user
inserts/updates foreign table, but primary key is unique...
Vadim
