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
