From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Jerry Gamache <jerry(dot)gamache(at)idilia(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze |
Date: | 2010-02-10 19:19:24 |
Message-ID: | 20100210191924.GQ4922@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jerry Gamache | 2010-02-10 19:49:34 | Re: BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze |
Previous Message | Jerry Gamache | 2010-02-10 19:16:32 | Re: BUG #5321: Parallel restore temporarily deadlocked by autovacuum analyze |