On Sep23, 2011, at 18:03 , Magnus Hagander wrote: > On Sep 23, 2011 5:59 PM, "Alvaro Herrera" <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
