Hi Stephen! Stephen Frost [2006-02-06 20:52 -0500]: > > ------ snip ------- > > 1. Add and ship /etc/postgresql/pg_upgradecluster.d/. Scripts in that > > directory will be called with the following arguments: > > > > <old version> <cluster name> <new version> <phase> > > > > <phase> is 'init' right after creating a virgin cluster of > > <newversion>, and 'finish' after all the data from the old version > > cluster has been dumped/reloaded into the new one. > > Looks good. Is there any need to pass the username to use to connect to > the database as superuser? I'm guessing no but thought I might mention > it...
The owner can be figured out easily with pg_lsclusters or some ls command, but indeed just passing it to the hook scripts is easier. So: <old version> <cluster name> <new version> <superuser> <phase> > > 2. Change pg_upgradecluster to not restore objects which are already > > present in the new cluster. > > [...] > > This looks good, the only thing I think we need to double-check is how > data is handled (ie: is the data portion a seperate 'object' which needs > to be filtered somehow, or is it associated with the base 'object', ie: > table, that the data is from?). Assuming the above handles the data as > well as the actual object itself then it should work well. The definition and content is just one object in the list. but that should be a mere implementation detail that shouldn't affect the spec wrt. hook scripts. > > - Does that per-cluster .d hook directory accomodate the needs of > > PostGIS? Would a per-database hook be better? > > From my point of view, I'd think a per-database hook would probably > better. How should that look like then? The db's are certainly in place in the 'finish' phase, but in the 'init' phase there are just the usual template[01] and postgres databases. The destination databases are created in the pg_restore stage. It might be possible to pre-create empty destination databases right before calling the hooks with phase 'init' and change the hooks to be per-database. But that would become much more complicated and would involve a lot of hacking. If it's really necessary to make hooks for e. g. PostGIS work properly, then I'm willing to do that. But I'm not familiar with the steps to set up PostGIS, what needs to be done roughly? > An interesting question would be if there's some way to detect > if PostGIS is installed in a given database before running the install > routine on it. I guess an associated question is how template1 is > handled... Since the hooks can access the old cluster, they should be able to figure that out on their own, right? > Is 'init' above after all databases have been created, or > after each one? As I expect you understand, if template1 is created and > then the init scripts run (which add PostGIS to template1) then it > wouldn't be necessary to run the init script on the 'regular' databases. > In that case the init scripts could be run per-cluster, provided it's > run after template1 is created but before any other databases are > created. Know what I mean? Yes, I think that's the question I raised above. If you could get away with just modifying template1, I would be happy. :) > > - Is the ignore scheme sketched above enough, or do we need > > additional 'no dump' blacklists? > > I was thinking about this and about upgrades. It's not uncommon for an > upgrade to obsolete one table such that it wouldn't exist in a new > install.. I'm not sure that'd actually be a problem though. Ok, then let's add that functionality when we really need it. Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates?
signature.asc
Description: Digital signature
