Re: Reliable WAL file shipping over unreliable network - Mailing list pgsql-admin

From Rui DeSousa
Subject Re: Reliable WAL file shipping over unreliable network
Date
Msg-id FB6AA142-81F4-4238-8456-E965555CDA44@icloud.com
Whole thread Raw
In response to Re: Reliable WAL file shipping over unreliable network  (Dianne Skoll <dfs@roaringpenguin.com>)
Responses Re: Reliable WAL file shipping over unreliable network  (Dianne Skoll <dfs@roaringpenguin.com>)
List pgsql-admin
You are dealing with a race condition. Postgres will continually attempt to archive the same file over and over until
rsyncfoolishly returns success.   

You are making the assumption that rsync removed the file? What if it can’t? If you’re dealing with a logged filesystem
andit can’t log the metafile changes what happens then? What happened when rsync core dumps?  

Why would you not use “-c”?  I have seen this fail without the “-c” option…


> On Feb 28, 2018, at 1:52 PM, Dianne Skoll <dfs@roaringpenguin.com> wrote:
>
> On Wed, 28 Feb 2018 13:49:33 -0500
> Rui DeSousa <rui.desousa@icloud.com> wrote:
>
>> Really? I think you really need to think about it.  You are dealing
>> with a race condition.
>
> Not at all, assuming rsync is being called by PostgreSQL's archive_command.
>
>> You are dealing with a race condition involving filesystem metadata.
>
> Nope.  Not true.  What are the things that are racing?
>
> If you rsync data to make a base backup, then yes, use -c... but not because
> of any race condition.  Instead, it's because of the coarse filesystem
> timestamp granularity.
>
> Regards,
>
> Dianne.
>



pgsql-admin by date:

Previous
From: Nagy László Zsolt
Date:
Subject: Re: Reliable WAL file shipping over unreliable network
Next
From: Dianne Skoll
Date:
Subject: Re: Reliable WAL file shipping over unreliable network