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
1. we already has lock with >= priority (currently, more
restrictive locks have greater priority);
2. lock requested doesn't conflict with lock of any waiters;
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.
In response to
pgsql-hackers by date
|Next:||From: Vadim Mikheev||Date: 1999-04-28 11:01:56|
|Subject: Re: [HACKERS] Lock freeze ? in MVCC|
|Previous:||From: Hiroshi Inoue||Date: 1999-04-28 09:57:52|
|Subject: RE: [HACKERS] Lock freeze ? in MVCC|