Re: parallel pg_restore - WIP patch - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: parallel pg_restore - WIP patch
Date
Msg-id 48E1A41B.4070207@dunslane.net
Whole thread Raw
In response to Re: parallel pg_restore - WIP patch  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: parallel pg_restore - WIP patch  (Philip Warner <pjw@rhyme.com.au>)
List 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




pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: parallel pg_restore - WIP patch
Next
From: Philip Warner
Date:
Subject: Re: parallel pg_restore - WIP patch