Re: [HACKERS] Lock freeze ? in MVCC

Hiroshi Inoue wrote:
> 
> > However, I'm not sure that proposed changes will help in the next case:
> >
> > session-1 => begin;
> > session-1 => insert into tt values (1);       --RowExclusiveLock
> >
> > session-2 => begin;
> > session-2 => insert into tt values (2);       --RowExclusiveLock
> >
> > session-3 => begin;
> > session-3 => lock table tt;                   --AccessExclusiveLock
> >                 (conflicts with 1 & 2)
> >                                 ^
> > session-1 => lock table tt in share mode;     --ShareLock
> >                 (conflicts with 2 & 3)
> >                                     ^
> > 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;
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.

Vadim