Re: [HACKERS] Lock freeze ? in MVCC

> Hiroshi Inoue wrote:
> >
> > Now I'm suspicious about the following code in LockResolveConflicts().
> >
> > /*
> > * We can control runtime this option. Default is lockReadPriority=0
> > */
> > if (!lockReadPriority)
> > {
> > /* ------------------------
> > * If someone with a greater priority is waiting for the
> > lock,
> > * do not continue and share the lock, even if we can. bjm
> > * ------------------------
>
> You're right Hiroshi - this must be changed:
>
> if we already have some lock with priority X and new requested
> lock has priority Y, Y <= X, then lock must be granted.
>
> Also, I would get rid of lockReadPriority stuff...
>
> Bruce, what do you think?

This sounds correct. I thought I needed to have the queue ordering
changed so that row-level locks are queued before table-level locks,
because there could be cases of lock escalation from row-level to
table-level.

However, it seems the problem is that readers don't share locks if
writers are waiting. With table-level locks, you never escalated a read
lock because you had already locked the entire table, while now you do.
Perhaps we can tell the system not to share read locks unless you are
sharing your own lock due to a lock escalation.

lockReadPriority() was probably added by Massimo to disable this "don't
share a readlock if another writer is waiting" behavior. While
disabling this behavior my be useful in some cases, but in the general
case may be a problem of starving writers if there are too many readers.

However, it is my understanding that we don't have readers sleeping on
locks anymore, but I may be wrong.

--
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