Re: [HACKERS] Lock freeze ? in MVCC

Hiroshi Inoue wrote:
>
> >
> > if someone is waiting for lock then we must not take them
> > into account (and skip to check for conflicts with lock
> > holders) if
> >
> > 1. we already has lock with >= priority (currently, more
> > restrictive locks have greater priority);
> > or
> > 2. lock requested doesn't conflict with lock of any waiters;
>
> Does this mean that the lock has a low priority ? If so,this

Yes and no -:)

If we acquire ShareLock (prio 4) and someone with RowShareLock (2)
is waiting then this means that table is locked in ExclusiveLock
(or AccessExclusiveLock) mode and we'll going to sleep after
lock-holder conflict test (so, we could go to sleep just after
seeing that our prio is higher, without lock-holder conflict test).

If we acquire RowShareLock and someone with ShareLock is
waiting due to table is locked in RowExclusiveLock mode then
we are allowed to continue: ShareLock waiter will be wakeupd
after releasing of RowExclusiveLock and we don't conflict
with any of these lock mode.

> state(2.) is hardly changed. When this waiter is wakeupd ?
>
> > or
> > 3. conflicting waiter is waiting for us: its lock conflicts
> > with locks we already hold, if any.
> >
> > I foresee that we also will have to change lock queue ordering
> > code but I have to think about it more.
> >
>
> Do you say about the following stuff in ProcSleep() ?
>
> proc = (PROC *) MAKE_PTR(waitQueue->links.prev);
>
> /* If we are a reader, and they are writers, skip past them */
> for (i = 0; i < waitQueue->size && proc->prio > prio; i++)
> proc = (PROC *) MAKE_PTR(proc->links.prev);
>
> /* The rest of the queue is FIFO, with readers first, writers last */
> for (; i < waitQueue->size && proc->prio <= prio; i++)
> proc = (PROC *) MAKE_PTR(proc->links.prev);
>
> Seems above logic is only for 2 levels of priority(READ/WRITE).
> But it's difficult for me to propose a different design for this.

Yes. I'm not sure how useful is priority logic now.

Keep thinking...

Vadim