Re: pg_upgrade and rsync

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

On Mon, Jan 26, 2015 at 05:41:59PM -0500, Stephen Frost wrote:
> I've thought about it a fair bit actually and I agree that there is some
> risk to using rsync for *incremental* base backups. That is, you have
> a setup where you loop with:
>
> pg_start_backup
> rsync -> dest
> pg_stop_backup
>
> without using -I, changing what 'dest' is, or making sure it's empty
> every time. The problem is the 1s-level granularity used on the
> timestamp. A possible set of operations, all within 1s, is:
>
> file changed
> rsync starts copying the file
> file changed again (somewhere prior to where rsync is at)
> rsync finishes the file copy
>
> 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?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-01-28 02:41:15 Re: pg_upgrade and rsync
Previous Message Robert Haas 2015-01-28 02:16:41 Re: Parallel Seq Scan