Re: parallel pg_restore - WIP patch

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Russell Smith <mr-russ(at)pws(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeffrey Baker <jwbaker(at)gmail(dot)com>
Subject: Re: parallel pg_restore - WIP patch
Date: 2008-09-29 12:32:31
Message-ID: 48E0CADF.8000009@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
>
>> pg_restore: [archiver (db)] could not execute query: ERROR: deadlock
>> detected
>> DETAIL: Process 18100 waits for AccessExclusiveLock on relation
>> 1460818342 of database 1460815284; blocked by process 18103.
>> Process 18103 waits for AccessExclusiveLock on relation 1460818336 of
>> database 1460815284; blocked by process 18100.
>> HINT: See server log for query details.
>>
>
>
>> ALTER TABLE ONLY foo
>> ADD CONSTRAINT fk_av_relations_av FOREIGN KEY (vs_id) REFERENCES
>> bar ...
>>
>
> Hmm, I'll bet the restore code doesn't realize that this can't run in
> parallel with index creation on either table ...
>
>
>

Yeah. Of course, it's never needed to bother with stuff like that till now.

The very simple fix is probably to run a separate parallel cycle just
for FKs, after the index creation.

A slightly more elegant fix would probably be to add dependencies from
each index that might cause this to the FK constraint.

I'll work on the first for now.

Is there any chance that the locks we're taking here are too strong?
Intuitively it looks a bit like it.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-09-29 12:33:16 Re: [PATCHES] Infrastructure changes for recovery
Previous Message Tom Lane 2008-09-29 12:28:15 Re: Proposal: move column defaults into pg_attribute along with attacl