Re: pg_upgrade and rsync - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pg_upgrade and rsync
Date
Msg-id 20150123015447.GI3854@tamriel.snowman.net
Whole thread Raw
In response to Re: pg_upgrade and rsync  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade and rsync
Re: pg_upgrade and rsync
Re: pg_upgrade and rsync
List pgsql-hackers
* Bruce Momjian (bruce@momjian.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

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: tracking commit timestamps
Next
From: Petr Jelinek
Date:
Subject: Re: Using 128-bit integers for sum, avg and statistics aggregates