Re: Deadlock possibility in _bt_check_unique?
| От | Gokulakannan Somasundaram |
|---|---|
| Тема | Re: Deadlock possibility in _bt_check_unique? |
| Дата | |
| Msg-id | 9362e74e1003231156g2a0b8414gf57b26e209b869a0@mail.gmail.com обсуждение |
| Ответ на | Re: Deadlock possibility in _bt_check_unique? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Deadlock possibility in _bt_check_unique?
Re: Deadlock possibility in _bt_check_unique? |
| Список | pgsql-hackers |
> T2 : session 1 releases the lock on p1 (its waiting to acquire a ex lock onThat's not what we do. See _bt_findinsertloc.
> p2)
regards, tom lane
I am really confused. Please keep the cool and explain me, if i am wrong. I could see this code in _bt_findinsertloc. There is a _bt_relandgetbuf, which releases lock on p1 and tries to acquire a lock on p2. I wrote ex lock in the place of BT_WRITE.
00589 for (;;)What is that, i am missing here?
00590 {
00591 BlockNumber rblkno = lpageop->btpo_next;
00592
00593 rbuf = _bt_relandgetbuf(rel, rbuf, rblkno, BT_WRITE);
00594 page = BufferGetPage(rbuf);
00595 lpageop = (BTPageOpaque) PageGetSpecialPointer(page);
00596 if (!P_IGNORE(lpageop))
00597 break;
00598 if (P_RIGHTMOST(lpageop))
00599 elog(ERROR, "fell off the end of index \"%s\"",
00600 RelationGetRelationName(rel));
00601 }
Gokul.
В списке pgsql-hackers по дате отправления: