Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Lock freeze ? in MVCC

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Vadim MikheevDate: 1999-04-28 11:01:56
Subject: Re: [HACKERS] Lock freeze ? in MVCC
Previous:From: Hiroshi InoueDate: 1999-04-28 09:57:52
Subject: RE: [HACKERS] Lock freeze ? in MVCC

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group