From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] Lock freeze ? in MVCC |
Date: | 1999-04-27 10:24:07 |
Message-ID: | 000f01be9098$150c29e0$2801007e@cadzone.tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Bruce Momjian [mailto:maillist(at)candle(dot)pha(dot)pa(dot)us]
> Sent: Tuesday, April 27, 1999 1:33 PM
> To: Hiroshi Inoue
> Cc: pgsql-hackers(at)postgreSQL(dot)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 priority is 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(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-04-27 10:48:30 | Re: [HACKERS] Lock freeze ? in MVCC |
Previous Message | Chris Bitmead | 1999-04-27 10:18:00 | Re: [HACKERS] It would be nice if this could be fixed... |