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
notthat 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
shellscript instead of directly modifying things itself? Or perhaps some custom "command file" that could then be
replayedby pg_upgrade on another server? Of course, that's assuming that replicas are compatible enough with masters
forthat 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