Re: pg_upgrade and rsync

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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-26 22:11:08
Message-ID: 54C6BB7C.1000408@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/23/15 12:40 PM, Stephen Frost wrote:
>> >That said, the whole timestamp race condition in rsync gives me the heebie-jeebies. For normal workloads maybe it's not that big a deal, but when dealing with fixed-size data (ie: Postgres blocks)? Eww.
> The race condition is a problem for pg_start/stop_backup and friends.
> In this instance, everything will be shut down when the rsync is
> running, so there isn't a timestamp race condition to worry about.

Yeah, I'm more concerned about people that use rsync to take base backups. Do we need to explicitly advise against that? Is there a way to work around this with a sleep after pg_start_backup to make sure all timestamps must be different? (Admittedly I haven't fully wrapped my head around this yet.)

>> >How horribly difficult would it be to allow pg_upgrade to operate on multiple servers? Could we have it create a shell script instead of directly modifying things itself? Or perhaps some custom "command file" that could then be replayed by pg_upgrade on another server? Of course, that's assuming that replicas are compatible enough with masters for that to work...
> Yeah, I had suggested that to Bruce also, but it's not clear why that
> would be any different from an rsync --size-only in the end, presuming
> everything went according to plan.

Yeah, if everything is shut down maybe we're OK.
--
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 Robert Haas 2015-01-26 22:11:32 Re: New CF app deployment
Previous Message Jim Nasby 2015-01-26 22:01:52 Re: proposal: searching in array function - array_position