Re: BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze |
Дата | |
Msg-id | 20100210191924.GQ4922@alvh.no-ip.org обсуждение исходный текст |
Ответ на | BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze ("Jerry Gamache" <jerry.gamache@idilia.com>) |
Ответы |
Re: BUG #5321: Parallel restore temporarily deadlocked by
autovacuum analyze
|
Список | pgsql-bugs |
Jerry Gamache wrote: > I was not able to repro with default parameters, or at 15s naptime, > and at 1s naptime I got only 1deadlock in 3 tests. > > This time the deadlock was with table_a, table_b and table_c > (table_x and table_y were not involved). > > 18395 | database1 | autovacuum: ANALYZE public.table_a > 18406 | database1 | autovacuum: ANALYZE public.table_b > 18510 | database1 | > : CREATE UNIQUE INDEX index_bg ON table_b > USING btree (col_g); > 18567 | database1 | autovacuum: ANALYZE public.table_c > 18802 | database1 | select procpid,datname,current_query from > pg_stat_activity where datname='database1' ORDER BY procpid; > > There is a FK constraint between table_a and table_b, but table_c > does not have any direct constraint relation with the other 2 > tables. > > The logs show that the autovacuum of table_b was canceled 20 minutes > ago, but the thread is still alive and blocked. That's pretty strange. Can we see a pg_locks snapshot? (Please attach as a text file so that it doesn't get word-wrapped) -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-bugs по дате отправления: