Re: parallel pg_restore - WIP patch
От | Andrew Dunstan |
---|---|
Тема | Re: parallel pg_restore - WIP patch |
Дата | |
Msg-id | 48E0E546.9030204@dunslane.net обсуждение исходный текст |
Ответ на | Re: parallel pg_restore - WIP patch (Dimitri Fontaine <dfontaine@hi-media.com>) |
Список | pgsql-hackers |
Dimitri Fontaine wrote: > Le lundi 29 septembre 2008, Tom Lane a écrit : > >> * Extend the archive format to provide some indication that "restoring >> this object requires exclusive access to these dependencies". >> >> * Hardwire knowledge into pg_restore that certain types of objects >> require exclusive access to their dependencies. >> > > Well, it seems to me that currently the FK needs in term of existing indexes > and locks, and some other object lock needs, are all hardwired. Is it even > safe to consider having the locks needed for certain commands not be > hardwired? > > Provided I'm not all wrong here, I don't see how having something more > flexible at restore time than at build time is a win. The drawback is that > whenever you change a lock need in commands, you have to remember teaching > pg_restore about it too. > > So my vote here is in favor of hardwired knowledge of pg_restore, matching > target server code assumptions and needs. > > Well, I've had to use some knowledge of various item types already, and I have been trying not to disturb pg_dump also, so I'm inclined to build this knowledge into pg_restore. ISTM that "things that will have lock conflicts" are different and more target version dependent than "things that logically depend on other things", so we can still rely on pg_dump to some extent to provide the latter while building the former at restore time. cheers andrew
В списке pgsql-hackers по дате отправления: