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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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