RE: [HACKERS] Lock freeze ? in MVCC

> -----Original Message-----
> From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
> Sent: Tuesday, April 27, 1999 1:33 PM
> To: Hiroshi Inoue
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] Lock freeze ? in MVCC
>
>
> OK, let me comment on this.  It does not to see this as a deadlock
> because session 3 really doesn't have a lock at the point it is hanging.
> A deadlock would be if 1 has a lock that 3 is waiting for, and 3 has a
> lock 1 is waiting for.
>
> Hold on, I think I see what you are saying now.  It seems the locking
> code assume table-level locking, while the new code now has MVCC.  I
> better look at this.  This could be ugly to fix.  I look for matching

I think it's a problem of table-level locking(MVCC has 8 levels of table-
locking and even select operations acquire AccessShareLock's.)
Moreover I found it's not the problem of MVCC only.
In fact I found the following case in 6.4.2.

session-1 => create table tt (id int4);

session-1 => begin;
session-1 => select * from tt;

session-2 => begin;
session-2 => select * from tt;

session-3 => begin;
session-3 => lock table tt;        (blocked)

session-1 => select * from tt;        (blocked)

session-2 => end;

session-2 returns immediately,but session-3 and session-1
are still blocked

Now I'm suspicious about the following code in LockResolveConflicts().
        /*        * We can control runtime this option. Default is lockReadPriority=0        */       if
(!lockReadPriority)      {               /* ------------------------                * If someone with a greater
priorityis waiting for the
 
lock,                * do not continue and share the lock, even if we can.  bjm                *
------------------------               */               int                     myprio =
 
LockMethodTable[lockmethod]->ct
l->prio[lockmode];               PROC_QUEUE *waitQueue = &(lock->waitProcs);               PROC       *topproc = (PROC
*)
MAKE_PTR(waitQueue->links.prev);
               if (waitQueue->size && topproc->prio > myprio)               {
XID_PRINT("LockResolveConflicts:higher priority
 
proc wa
iting",                                         result);                       return STATUS_FOUND;               }
 }
 


After I removed above code on trial,select operations in my example case
are not blocked.

Comments ?

Thanks.

Hiroshi Inoue
Inoue@tpf.co.jp