Re: Hot Backup with rsync fails at pg_clog if under load
От | Florian Pflug |
---|---|
Тема | Re: Hot Backup with rsync fails at pg_clog if under load |
Дата | |
Msg-id | 612DC4A7-1938-404B-84CE-9F5AD49016F4@phlo.org обсуждение исходный текст |
Ответ на | Re: Hot Backup with rsync fails at pg_clog if under load (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
On Sep23, 2011, at 18:03 , Magnus Hagander wrote: > On Sep 23, 2011 5:59 PM, "Alvaro Herrera" <alvherre@commandprompt.com> wrote: > > 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? I don't see how it could be forbidden. ISTM that we absolutely *have* to be able to deal with each byte of a file's date, including it's meta-data, being in any state it was between the time pg_start_backup() returned and pg_stop_backup() was issued. With the individual states being in no way synchronized. (OK, in reality restricting this to individual 512-byte blocks is probably enough, but still...). This, I think, is also the reasons we need to force full_page_writes to on during a hot backup. If a page was modified at all between pg_start_backup() and pg_stop_backup(), we essentially have to assume it's totally garbled. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: