Horton

Re: parallel pg_restore - WIP patch

Philip Warner <pjw@rhyme.com.au>

View thread
From: Philip Warner <pjw@rhyme.com.au>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, Tom Lane <tgl@sss.pgh.pa.us>, Russell Smith <mr-russ@pws.com.au>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Jeffrey Baker <jwbaker@gmail.com>
Date: 2008-09-30T03:26:00Z
Lists: pgsql-hackers 
>
> + 					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).