Re: Using pg_upgrade on log-shipping standby servers

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using pg_upgrade on log-shipping standby servers
Date: 2012-07-20 17:11:11
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Fri, Jul 20, 2012 at 12:39:12PM -0400, Aidan Van Dyk wrote:
> 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.

I am not sure what a base backup is buying us here --- base backup is
designed to create a backup while the server is running, and it is down
at that point. I think what you are suggesting is to make a data dir
copy while just the schema is in place. That is possible, but it opens
up all kinds of possible failure cases because pg_upgrade operations
have to be done in a specific order --- it feels very fragile.

I think the commands to run after pg_upgrade --link completes on both
primary and standby might be as easy as:

cd /u/pg/pgsql.old/data
find . -links 1 -exec cp {} /u/pgsql/data \;

Why would we want anything more complicated than this?

Bruce Momjian <bruce(at)momjian(dot)us>

+ It's impossible for everything to be true. +

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-07-20 17:12:32 Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)
Previous Message Aidan Van Dyk 2012-07-20 16:39:12 Re: Using pg_upgrade on log-shipping standby servers