Re: Hot Backup with rsync fails at pg_clog if under load

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Hot Backup with rsync fails at pg_clog if under load
Дата
Msg-id 4E7CB603.2060200@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Hot Backup with rsync fails at pg_clog if under load  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On 23.09.2011 19:03, Magnus Hagander wrote:
> On Sep 23, 2011 5:59 PM, "Alvaro Herrera"<alvherre@commandprompt.com>
> wrote:
>>
>>
>> Excerpts from Linas Virbalas's message of vie sep 23 09:47:20 -0300 2011:
>>> On 9/23/11 12:05 PM, "Heikki Linnakangas"
>>> <heikki.linnakangas@enterprisedb.com>  wrote:
>>
>>> But on the standby its size is the old one (thus, it seems, that the
> size
>>> changed after the rsync transfer and before the pg_stop_backup() was
>>> called):
>>>
>>> ls -l pg_clog/
>>> total 8
>>> -rw------- 1 postgres postgres 8192 Sep 23 14:31 0000
>>
>> Sounds like rsync is caching the file size at the start of the run, and
>> then copying that many bytes, ignoring the growth that occurred after it
>> started.
>
> That pretty much matches what Daniel does when he got the same failure case.
>
> Is this not allowed? Shouldn't wal replay fix this?

That's OK. The effect is the same as if rsync had copied the file at the 
start.

What's not OK is to store the file as empty or truncated file in the 
backup, when the file is deleted from pg_clog while rsync is running. 
The file must have length >= the length the file had when backup 
started, or the file must be omitted from the backup altogether.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: citext operator precedence fix
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Hot Backup with rsync fails at pg_clog if under load