Re: parallel pg_restore - WIP patch
От | Andrew Dunstan |
---|---|
Тема | Re: parallel pg_restore - WIP patch |
Дата | |
Msg-id | 48E1A41B.4070207@dunslane.net обсуждение исходный текст |
Ответ на | Re: parallel pg_restore - WIP patch (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: parallel pg_restore - WIP patch
|
Список | 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 по дате отправления: