Re: Add progressive backoff to XactLockTableWait functions
От | Xuneng Zhou |
---|---|
Тема | Re: Add progressive backoff to XactLockTableWait functions |
Дата | |
Msg-id | CABPTF7Vhh7aS9qpU6oBJ=iqS5zgNS5AhB6bLj-+hS6cMhgLvZg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add progressive backoff to XactLockTableWait functions (Xuneng Zhou <xunengzhou@gmail.com>) |
Список | pgsql-hackers |
Hi, After studying proarray and lmgr more closely, I have found several critical issues in the two patches and underestimated their complexity and subtlety. Sorry for posting immature patches that may have created noise. I now realize that making lock acquisition— (void) LockAcquire(&tag, ShareLock, false, false); in XactLockTableWait work on a standby, following Andres’ first suggestion, may be simpler and require fewer new helpers. XactLockTableWait fails on a standby simply because we never call XactLockTableInsert. I am considering invoking XactLockTableInsert when an XID is added to KnownAssignedXids, and XactLockTableDelete(the constraint for delete now is not used for main xid in primary) when it is removed. A preliminary implementation and test shows this approach kinda works, but still need to confirm it is safe on a standby and does not break other things. patched: Performance counter stats for process id '2331196': 233,947,559 cycles 106,270,044 instructions # 0.45 insn per cycle 12,464,449 cache-misses 9,397 context-switches 60.001191369 seconds time elapsed head: Performance counter stats for process id '2435004': 1,258,615,994 cycles 575,248,830 instructions # 0.46 insn per cycle 72,508,027 cache-misses 43,791 context-switches 60.001040589 seconds time elapsed Best, Xuneng
Вложения
В списке pgsql-hackers по дате отправления: