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

Re: parallel pg_restore - WIP patch

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-30 03:59:23
Message-ID: 48E1A41B.4070207@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Philip Warner wrote:
>> + 					if (strcmp(te->desc,"CONSTRAINT") == 0 ||
>> + 						strcmp(te->desc,"FK CONSTRAINT") == 0 ||
>> + 						strcmp(te->desc,"CHECK CONSTRAINT") == 0 ||
>> + 						strcmp(te->desc,"TRIGGER") == 0 ||
>> + 						strcmp(slots[i].te->desc,"CONSTRAINT") == 0 ||
>> + 						strcmp(slots[i].te->desc,"FK CONSTRAINT") == 0 ||
>> + 						strcmp(slots[i].te->desc,"CHECK CONSTRAINT") == 0 ||
>> + 						strcmp(slots[i].te->desc,"TRIGGER") == 0)
>>   
>>     
> Really just an observation from the peanut gallery here, but every time
> pg_restore hard-codes this kind of thing, it introduces yet another
> possible side-effect bug when someone, eg, adds a new TOC type.
>
> Would it substantially decrease the benefits of the patch to skip *any*
> toc entry that shares dependencies with another? (rather than just those
> listed above).
>
>
>   

Unfortunately, it quite possibly would. You would not be able to build 
two indexes on the same table in parallel, even though they wouldn't 
have conflicting locks.

cheers

andrew



In response to

Responses

pgsql-hackers by date

Next:From: Philip WarnerDate: 2008-09-30 04:13:06
Subject: Re: parallel pg_restore - WIP patch
Previous:From: Philip WarnerDate: 2008-09-30 03:26:00
Subject: Re: parallel pg_restore - WIP patch

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