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
