Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group