RE: [HACKERS] Lock freeze ? in MVCC

> -----Original Message-----
> From: root(at)sunpine(dot)krs(dot)ru [mailto:root(at)sunpine(dot)krs(dot)ru]On Behalf Of Vadim
> Mikheev
> Sent: Wednesday, April 28, 1999 7:56 PM
> To: Hiroshi Inoue
> Cc: Bruce Momjian; pgsql-hackers(at)postgreSQL(dot)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(at)tpf(dot)co(dot)jp