| From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Russell Smith <mr-russ(at)pws(dot)com(dot)au>, Jeffrey Baker <jwbaker(at)gmail(dot)com> |
| Subject: | Re: parallel pg_restore - WIP patch |
| Date: | 2008-09-29 13:51:40 |
| Message-ID: | 200809291551.42729.dfontaine@hi-media.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Regards,
--
dim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2008-09-29 13:53:28 | Re: [PATCHES] Infrastructure changes for recovery |
| Previous Message | Tom Lane | 2008-09-29 13:46:08 | Re: FSM rewrite: doc changes |