Hey Martin,

* Martin Pitt ([EMAIL PROTECTED]) wrote:
> Thanks for today's IRC discussion, I'll try to summarize and create a
> mini-spec:

Very nice, thanks. :)

> ------ 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...

>  2. Change pg_upgradecluster to not restore objects which are already
>  present in the new cluster.
> 
>   - after initializing the new cluster and calling pg_upgradecluster.d
>     scripts with phase init, record already existing objects and
>     databases:
>  
>      pg_dump -Fc --schema-only $db | pg_restore -l > /tmpdir/ignore-$db
> 
>   - determine set of objects that need to be restored from the old
>     cluster:
> 
>      pg_dump -Fc --schema-only $db | pg_restore -l | sortmagic | > 
> /tmpdir/restore-$db
> 
>     sortmagic is some perl code snippet which ignores all objects that
>     occur in ignore-$db.
> 
>   - add -L /tmpdir/restore-$db argument to pg_restore call

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.

>  - 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.  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...  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?

>  - 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.

        Thanks!

                Stephen

Attachment: signature.asc
Description: Digital signature

Reply via email to