Re: Recovery inconsistencies, standby much larger than primary
От | Tom Lane |
---|---|
Тема | Re: Recovery inconsistencies, standby much larger than primary |
Дата | |
Msg-id | 18168.1392234917@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Recovery inconsistencies, standby much larger than primary (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Recovery inconsistencies, standby much larger than primary
|
Список | pgsql-hackers |
Greg Stark <stark@mit.edu> writes: > On Wed, Feb 12, 2014 at 6:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Greg Stark <stark@mit.edu> writes: >>> This does possibly allocate an extra block past the target block. I'm >>> not sure how surprising that would be for the rest of the code. >> Should be fine; we could end up with an extra block after a failed >> extension operation in any case. > I know it's fine on the active database, I'm not so clear whether it's > compatible with the xlog records from the primary. I suppose it'll > just see an Initialize Page record and happily see the nul block and > initialize it. It's still a bit scary. Well, we can easily find uninitialized extra pages on the primary too, so if WAL replay were unable to cope with that, it would be a bug regardless. >> Huh? Bug in wal-e? What bug? > WAL-E actually didn't restore a whole 1GB file due to a transient S3 > problem, in fact a bunch of them. Hah. Okay, I think we can write this issue off as closed then. regards, tom lane
В списке pgsql-hackers по дате отправления: