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 | 213AEFBF-479C-4F9E-B0CA-24AAB2C9F4DD@phlo.org обсуждение исходный текст |
Ответ на | Re: Hot Backup with rsync fails at pg_clog if under load (Daniel Farina <daniel@heroku.com>) |
Ответы |
Re: Hot Backup with rsync fails at pg_clog if under load
|
Список | pgsql-hackers |
On Oct23, 2011, at 22:48 , Daniel Farina wrote: > It doesn't seem meaningful for StartupCLOG (or, indeed, any of the > hot-standby path functionality) to be called before that code is > executed, but it is anyway right now. I think the idea is to check that the CLOG part which recovery *won't* overwrite is consistent (or rather, given the simplicity of the check, at least accessible) Heikki said the following somewhere else in this thread when I suggested something similar to your proposal: >> There are pretty clear rules on what state clog can be in. When you launch postmaster in a standby: >> >> * Any clog preceding the nextXid from the checkpoint record we start recovery from, must either be valid, or the clogfile must be missing altogether (which can happen when it was vacuumed away while the backup in progress - if the clogis still needed at the end of backup it must not be missing, of course). >> * Any clog following nextXid can be garbled or missing. >> >> Recovery will overwrite any clog after nextXid from the WAL, but not the clog before it. I think Simon's theory that we're starting recovery from the wrong place, i.e. should start with an earlier WAL location, is probably correct. The question is, why? best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: