Re: Hot Backup with rsync fails at pg_clog if under load
От | Aidan Van Dyk |
---|---|
Тема | Re: Hot Backup with rsync fails at pg_clog if under load |
Дата | |
Msg-id | CAC_2qU-Km5FW9qXDEduv7K0S7tUTk==+tp=ZjdrFbpdbWZc-2w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hot Backup with rsync fails at pg_clog if under load (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Hot Backup with rsync fails at pg_clog if under load
|
Список | pgsql-hackers |
On Fri, Sep 23, 2011 at 4:41 AM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: >> Unfortunately, it's impossible, because the error message "Could not read >> from file "pg_clog/0001" at offset 32768: Success" is shown (and startup >> aborted) before the turn for "redo starts at" message arrives. > > It looks to me that pg_clog/0001 exists, but it shorter than recovery > expects. Which shouldn't happen, of course, because the start-backup > checkpoint should flush all the clog that's needed by recovery to disk > before the backup procedure begins to them. I think the point here is that recover *never starts*. Something in the standby startup is looking for a value in a clog block that recovery hadn't had a chance to replay (produce) yet. So the standby is looking into the data directory *before* recovery has had a chance to run, and based on that,goes to look for something in clog page that wasn't guarenteed to exists at the start of the backup period, and bombing out before recovery has a chance to start replaying WAL and write the new clog page. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
В списке pgsql-hackers по дате отправления: