Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY
От
Alvaro Herrera
Тема
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY
Дата
Msg-id
20180103142700.sgbdcjx5fjajqj4h@alvherre.pgsql
Ответ на
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY (Andres Freund)
Список
Дерево обсуждения
pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Andres Freund <andres@anarazel.de>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Robert Haas <robertmhaas@gmail.com>
Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY Tom Lane <tgl@sss.pgh.pa.us>
Hello, Andres Freund wrote: > On 2018-01-03 02:20:14 +0000, Alvaro Herrera wrote: > > Include an isolationtester spec that 8 out of 10 times reproduces the > > deadlock with the unpatched code for me (Álvaro). > > The isolation test doesn't appear to be fully stable: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=baiji&dt=2018-01-03%2003%3A00%3A01 Yeah, thanks for reporting that. It's annoying, but obvious in hindsight -- the second process occasionally gets stuck waiting for the first one to release its snapshot. I can reproduce this about half the time, by adding a 100ms sleep in ProcessUtilitySlow right after the DefineIndex call. I can turn the isolation test to produce the output where s2 waits (without the sleep) if I introduce a third session s3 to lock s2; then releasing the lock in s3 causes both s1 and s2 to complete. I think the completions would be reported always in that order because of the way isolationtester verifies suspension. However this means that the test will get removed in 9.4 and 9.5 because isolationtester is not smart enough there. I suppose the other option would be to add an alternate expected file for the test. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-committers по дате отправления
От: Alvaro Herrera
Дата: