Re: [HACKERS] FOR SHARE LOCK clause ?]

Bruce Momjian wrote:
> 
> >
> > If you are going to set the 'table lock' at 2...why not just do the table
> > lock period?  From what youexplain above, a table lock won't affect a
> > read, only other writes...?
> 
> Good point.  I am assuming he is doing some kind of row-level locking
> for shared and write locks.  I can only guess this from his statement
> that shared locking of every row would be a problem.
> 
> Sounds like my explaination may be wrong, because it is saying he has
> some kind of row-locking going, perhaps for writes.  Maybe he is using
> the fact that if a writer is going to update a row that has a
> superceeded transaction id that is marked 'in progress' the writer has
> to wait for the transaction to finish.  If you do this, muliple writers
> can update at the same time, making MVCC better than row-level locking
> systems.

Yes. When transaction begins it places exclusive lock
for transaction ID in pseudo-table (no wait because of ID
is unique). If other writer sees that t_xmax is valid 
(and not committed/aborted) transaction ID then it tries 
to place share lock for t_xmax in this pseudo-table.
If t_xmax is running then concurrent writer will wait for
t_xmax commit/abort when exclusive lock for t_xmax
is released. With this technique writers use single
lmgr entry for all updated rows - just to let other
the-same-row writers know when transaction commits/aborts.

> 
> Readers don't block writers, and multiple writers can write as long as
> they are not touching the same rows.

Yes.

> In this scenario, shared locks are tricky, because the above system does
> not work.  You have to do some explicit locking, because reading does
> not set anything on the row.

Yes, but this will be user' decision to use FOR SHARE LOCK
(to lock rows explicitly) or not.

Vadim