Re: pg_upgrade and rsync

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, 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 01:54:47
Message-ID: 20150123015447.GI3854@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Fri, Jan 23, 2015 at 01:19:33AM +0100, Andres Freund wrote:
> > Or do you - as the text edited in your patch, but not the quote above -
> > mean to run pg_upgrade just on the primary and then rsync?
>
> No, I was going to run it on both, then rsync.

I'm pretty sure this is all a lot easier than you believe it to be. If
you want to recreate what pg_upgrade does to a cluster then the simplest
thing to do is rsync before removing any of the hard links. rsync will
simply recreate the same hard link tree that pg_upgrade created when it
ran, and update files which were actually changed (the catalog tables).

The problem, as mentioned elsewhere, is that you have to checksum all
the files because the timestamps will differ. You can actually get
around that with rsync if you really want though- tell it to only look
at file sizes instead of size+time by passing in --size-only. I have to
admit that for *my* taste, at least, that's getting pretty darn
optimistic. It *should* work, but I'd definitely recommend testing it
about a billion times in various ways before trusting it or recommending
it to anyone else. I expect you'd need --inplace also, for cases where
the sizes are different and rsync wants to modify the file on the
destination to match the one on the source.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2015-01-23 01:58:46 Re: Using 128-bit integers for sum, avg and statistics aggregates
Previous Message Petr Jelinek 2015-01-23 01:31:04 Re: tracking commit timestamps