Re: Recovery inconsistencies, standby much larger than primary
От | Tom Lane |
---|---|
Тема | Re: Recovery inconsistencies, standby much larger than primary |
Дата | |
Msg-id | 18334.1392321130@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: >> I think what you're arguing is that we should see WAL records filling the >> rest of segment 1 before we see any references to segment 2, but if that's >> the case then how did we get into the situation you reported? Or is it >> just that it was a broken base backup to start with? > The scenario I could come up with that didn't require a broken base backup > was that there was an earlier truncate or vacuum. So the sequence is high > offset reference, truncate, growth, crash. All possibly on a single > database. That's not really an issue, because then it would be OK to discard the high-offset update; we'd recognize that as safe when we replay the truncation. > It's possible we're better off not assuming we've thought of all possible > ways this can happen though. That's what's bothering me, too. On the other hand, if we can't think of a scenario where it'd be necessary to replay the high-offset update, then I'm disinclined to mess with the code further. regards, tom lane
В списке pgsql-hackers по дате отправления: