Re: [HACKERS] Lock freeze ? in MVCC
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Lock freeze ? in MVCC |
Дата | |
Msg-id | 199904270432.AAA03231@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Lock freeze ? in MVCC ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
RE: [HACKERS] Lock freeze ? in MVCC
|
Список | pgsql-hackers |
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 lock structure pointers in different backends(lock.c), but now I see that 1 and 2 both are waiting for table tt, but they have different locks structures, because they are different types of locks. Yikes. Maybe I can hack something in there, but I can't imagine how yet. Maybe Vadim will have a hint. --------------------------------------------------------------------------- session-1 => create table tt (id int4); session-1 => begin; session-1 => insert into tt values (1); session-2 => begin; session-2 => insert into tt values (2); session-3 => begin; session-3 => lock table tt; (blocked) session-1 => update tt set id=1 where id=1; (blocked) session-2 => end; session-2 returns immediately,but session-3 and session-1 are still blocked This phenomenon seems to be caused by LockResolveCon flicts() or DeadLockCheck(). Both session-1 and session-2 acquire RowExclusive locks by insert operations(InitPlan() in execMain.c). The AccessExclusive lock of session-3 is queued waiting for the release of above locks. When the update operation of session-1 is executed,the second RowExclusive lock is rejected by LockResolve Conflicts() and queued after the AccessExclusive lock of session-3. The state is like deadlock but DeadLockCheck() doesn't regard the state as deadlock. Thanks. Hiroshi Inoue Inoue@tpf.co.jp -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: