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