Re: Reliable WAL file shipping over unreliable network

Поиск
Список
Период
Сортировка
От Rui DeSousa
Тема Re: Reliable WAL file shipping over unreliable network
Дата
Msg-id FB6AA142-81F4-4238-8456-E965555CDA44@icloud.com
обсуждение исходный текст
Ответ на Re: Reliable WAL file shipping over unreliable network  (Dianne Skoll <dfs@roaringpenguin.com>)
Ответы Re: Reliable WAL file shipping over unreliable network  (Dianne Skoll <dfs@roaringpenguin.com>)
Список 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 по дате отправления:

Предыдущее
От: Nagy László Zsolt
Дата:
Сообщение: Re: Reliable WAL file shipping over unreliable network
Следующее
От: Dianne Skoll
Дата:
Сообщение: Re: Reliable WAL file shipping over unreliable network