Re: pg_upgrade and rsync

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: pg_upgrade and rsync
Date: 2015-01-23 00:04:24
Message-ID: 54C19008.706@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/22/15 5:43 PM, Bruce Momjian wrote:
> This brings up the other problem that the mod times of the files are
> likely to be different between master and slave --- should I recommend
> to only use rsync --checksum?

I don't think so. AIUI if the timestamps are different the very next thing it does is run the checksum (which is expensive). So --checksum is just going to hurt.

> I am going to now conclude that rsync is never going to work for this,
> unless we have pg_upgrade preserve relfilenodes as well. However, I am
> not even sure that is possible due to conflicts with system table
> relfilenodes created in the new cluster.

We've previously talked about required steps before an upgrade; perhaps we need a way to force an OID/relfilenode change on the old server prior to upgrade.

Or, thinking outside the box here... could this type of stuff be done in postgres itself so we could generate wal that's shipped to standby's? That would allow doing this as part of the formal upgrade process without the need for preliminary steps.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2015-01-23 00:09:35 Re: TABLESAMPLE patch
Previous Message Andreas Karlsson 2015-01-22 23:55:21 Re: PATCH: Reducing lock strength of trigger and foreign key DDL