Re: regression, deadlock in high frequency single-row UPDATE
От | Mark Kirkwood |
---|---|
Тема | Re: regression, deadlock in high frequency single-row UPDATE |
Дата | |
Msg-id | 548AA8F4.3020905@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: regression, deadlock in high frequency single-row UPDATE (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: regression, deadlock in high frequency single-row UPDATE
|
Список | pgsql-bugs |
On 12/12/14 06:22, Alvaro Herrera wrote: > Before this can be committed I need an isolationtester spec file that > reproduces the problem. Now that I understand why it happens it should > be easy to produce: just have a transaction that does BEGIN, then the > insert, and keeps the transaction open; enough other sessions run the > UPDATE until the problem pops up. (Also, comments on > Would_MultiXactIdWait_Block need work.) > FWIW - I was having a look at the isolationtester spec. Playing with the pgbench setup to see the minimal number of session I needed to provoke the deadlock (unpatched 9.5 code) seemed to converge to about 4. I managed to still see 1 deadlock with each session only doing 1 transaction - i.e: $ pgbench -c 4 -C -n -t 1 -f query.sql deadlock ...which resulted in 1 deadlock. So we may be able to get a reasonable test case that shows this up! I'll take a look at setting up a test case later - but don't let that stop you doing it 1st :-) Cheers Mark
В списке pgsql-bugs по дате отправления: