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
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 |