RE: [HACKERS] Lock freeze ? in MVCC

> -----Original Message-----
> From: root@sunpine.krs.ru [mailto:root@sunpine.krs.ru]On Behalf Of Vadim
> Mikheev
> Sent: Wednesday, April 28, 1999 7:56 PM
> To: Hiroshi Inoue
> Cc: Bruce Momjian; pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] Lock freeze ? in MVCC
> 
> 
> Hiroshi Inoue wrote:
> >

[snip] 

> > > This is deadlock situation and must be handled by
> > > DeadLockCheck().
> > >
> > 
> > It's really a deadlock ?
> > Certainly end/abort of session-2 doesn't wakeup session-1/session3.
> 
> You're right again. 
> First, I propose the next changes in LockResolveConflicts():
> 
> 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 
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.

Thanks.

Hiroshi Inoue
Inoue@tpf.co.jp