Re: pg_upgrade and rsync

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: pg_upgrade and rsync
Дата
Msg-id 54C1B196.2060201@pgmasters.net
обсуждение исходный текст
Ответ на Re: pg_upgrade and rsync  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: pg_upgrade and rsync  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 1/22/15 8:54 PM, Stephen Frost wrote:
> The problem, as mentioned elsewhere, is that you have to checksum all
> the files because the timestamps will differ.  You can actually get
> around that with rsync if you really want though- tell it to only look
> at file sizes instead of size+time by passing in --size-only.  I have to
> admit that for *my* taste, at least, that's getting pretty darn
> optimistic.  It *should* work, but I'd definitely recommend testing it
> about a billion times in various ways before trusting it or recommending
> it to anyone else.  I expect you'd need --inplace also, for cases where
> the sizes are different and rsync wants to modify the file on the
> destination to match the one on the source.
>
I would definitely not feel comfortable using --size-only.

In addition, there is a possible race condition in rsync where a file
that is modified in the same second after rsync starts to copy will not
be picked up in a subsequent rsync unless --checksum is used.  This is
fairly easy to prove and is shown here:

https://github.com/pgmasters/backrest/blob/dev/test/lib/BackRestTest/BackupTest.pm#L1667

That means the rsync hot, then rsync cold method of updating a standby
is not *guaranteed* to work unless checksums are used.  This may seem
like an edge case, but for a small, active database it looks like it
could be a real issue.

--
- David Steele
david@pgmasters.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Using 128-bit integers for sum, avg and statistics aggregates
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Parallel Seq Scan