Re: [HACKERS] FOR SHARE LOCK clause ?]

> > I think lock escalation is nice. Locking every row makes for lock
> > resource problems. I would recommend locking a single row, and if a
> > second row needs to be locked, just escalate to lock the whole table...
> > if that can be done. This would seem to be the most reasonable and
> > easiest to do.
>
> Making two assumption here...first is that your explanation of MVCC is
> correct, second one being that my understanding of your explannation is
> correct...
>
> 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.

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

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.

Vadim is sleeping now, so I assume we will hear something from him this
evening.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026