From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hans Braxmeier <hans(dot)braxmeier(at)outlook(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Postgres Dump - Creating index never stops |
Date: | 2017-07-12 19:41:28 |
Message-ID: | 24671.1499888488@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hans Braxmeier <hans(dot)braxmeier(at)outlook(dot)com> writes:
> After restarting postgres (even with a new cluster) and creating a new database, postgres is hanging while extracting the dump: gunzip -c pixabay.gz | psql pixabay
> The log file shows that the autovacuum task is running (almost) endless...
> 2017-07-12 18:05:52.367 CEST [19586] hans(at)pixabay LOG: duration: 11.609 ms statement: CREATE INDEX photos_indexphoto_created ON photos_indexphoto USING btree (created);
> 2017-07-12 20:34:58.943 CEST [19626] ERROR: canceling autovacuum task
> 2017-07-12 20:34:58.943 CEST [19626] CONTEXT: automatic analyze of table "pixabay.public.photos_photo"
> 2017-07-12 20:34:59.942 CEST [19586] hans(at)pixabay LOG: duration: 8947575.013 ms statement: CREATE INDEX photos_photo_approved_by_id ON photos_photo USING btree (approved_by_id);
What that looks like is it took the system an unusually long time to
notice that it needed to cancel the autovacuum to avoid a deadlock
with the CREATE INDEX. Was either process consuming a noticeable
amount of CPU during that interval? Do you have deadlock_timeout
set higher than the default 1s?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2017-07-12 22:27:27 | Re: Very poor read performance, query independent |
Previous Message | Hans Braxmeier | 2017-07-12 19:00:45 | Postgres Dump - Creating index never stops |