From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Lock freeze ? in MVCC |
Date: | 1999-04-28 10:55:54 |
Message-ID: | 3726E93A.520E2971@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-04-28 11:01:56 | Re: [HACKERS] Lock freeze ? in MVCC |
Previous Message | Hiroshi Inoue | 1999-04-28 09:57:52 | RE: [HACKERS] Lock freeze ? in MVCC |