Re: Recovery inconsistencies, standby much larger than primary

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Recovery inconsistencies, standby much larger than primary
Дата
Msg-id CAM-w4HMcXAM-x1SRgOc1J2vz=hoP84YvO2xs=WGTw2vjpGzA7A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
<p dir="ltr"><br /><p dir="ltr">> I think what you're arguing is that we should see WAL records filling the<br />
>rest of segment 1 before we see any references to segment 2, but if that's<br /> > the case then how did we get
intothe situation you reported?  Or is it<br /> > just that it was a broken base backup to start with?<p
dir="ltr">Thescenario I could come up with that didn't require a broken base backup was that there was an earlier
truncateor vacuum. So the sequence is high offset reference, truncate, growth, crash. All possibly on a single
database.<pdir="ltr">It's possible we're better off not assuming we've thought of all possible ways this can happen
though.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: how set GUC_check_errhint_string in call_string_check_hook()
Следующее
От: David Beck
Дата:
Сообщение: New hook after raw parsing, before analyze