On Tue, Jan 27, 2015 at 09:44:51PM -0500, David Steele wrote: > On 1/27/15 9:32 PM, Bruce Momjian wrote > > Now, this isn't actually a problem for the first time that file is > > backed up- the issue is if that file isn't changed again. rsync won't > > re-copy it, but that change that rsync missed won't be in the WAL > > history for the *second* backup that's done (only the first), leading to > > a case where that file would end up corrupted. > > Interesting problem, but doesn't rsync use sub-second accuracy? > > > According to my empirical testing on Linux and OSX the answer is no: > rsync does not use sub-second accuracy. This seems to be true even on > file systems like ext4 that support millisecond mod times, at least it > was true on Ubuntu 12.04 running ext4. > > Even on my laptop there is a full half-second of vulnerability for > rsync. Faster systems may have a larger window.
OK, bummer. Well, I don't think we ever recommend to run rsync without checksums, but the big problem is that rsync doesn't do checksums by default. :-( pg_upgrade recommends using two rsyncs: To make a valid copy of the old cluster, use <command>rsync</> to create a dirty copy of the old cluster while the server is running, then shut down the old server and run <command>rsync</> again to update the copy with any changes to make it consistent. You might want to exclude some I am afraid that will not work as it could miss changes, right? When would the default mod-time checking every be safe? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
