Not a problem; as you should be archiving your WALs to multiple sites simultaneously. You’re DR site should not rely
onany resources stored at the primary site.
> On Mar 2, 2018, at 1:09 PM, Stephen Frost <sfrost@snowman.net> wrote:
>
> Greetings,
>
> * Rui DeSousa (rui.desousa@icloud.com) wrote:
>>> On Mar 1, 2018, at 12:21 AM, scott ribe <scott_ribe@elevated-dev.com> wrote:
>>> The false report of success is not good, but it's not the root problem.
>>
>> A false success if a problem; especially in this use case as the source WAL file will be deleted by Postgres before
itwas truly successful. While monitoring is nice to avoid the issue it is not a fix for the issue.
>>
>> I personally cannot recommend the use of rsync in this application for two reasons.
>
> There's a bigger problem that I'm amazed hasn't been brought up already-
> the rsync, copy, cp, whatever, may finish just fine and then the system
> that the WAL file was copied to crashes and you end up losing a bunch of
> WAL because none of these methods actually sync's the WAL to disk.
>
> No archive_command should ever return success until the WAL is actually
> written out to permanent storage and sync'd. That's what tools like
> pgBackRest do and is part of the reason why people really shouldn't try
> to hack up their own archive_command solution but should be using well
> tested existing solutions.
>
> Thanks!
>
> Stephen