If you're wanting to automatically do some upgrades wouldn't an easier route be:
1) run pg_upgrade, up to the point where it actually start's
copying/linking in old cluster data files, and stop the new
postmaster.
2) Take a "base backup" style copy (tar, rsync, $FAVOURITE) of the new
cluster (small, since without data files)
3) Have pg_upgrade leave a log of exactly which old cluster data files
go where in the new cluster
That way, anybody, any script, etc who wants to make a new "standby"
from and old one only needs the pg_upgrade base backup (which should
be small, no data, just catalog stuff), and the log of which old files
to move where.
The only pre-condition is that the standby's "old pg" *APPLIED* WAL up
to the exact same point as the master's "old pg". In that case the
standby's old cluster data files should same enough (maybe hint bits
off?) to be used.
a.
On Fri, Jul 20, 2012 at 12:25 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Jul 17, 2012 at 06:02:40PM -0400, Bruce Momjian wrote:
>> Second, the user files (large) are certainly identical, it is only the
>> system tables (small) that _might_ be different, so rsync'ing just those
>> would add the guarantee, but I know of no easy way to rsync just the
>> system tables.
>
> OK, new idea. I said above I didn't know how to copy just the non-user
> table files (which are not modified by pg_upgrade), but actually, if you
> use link mode, the user files are the only files with a hard link count
> of 2. I could create a script that copied from the master to the slave
> only those files with a link count of one.
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
