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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
