Re: Recovery inconsistencies, standby much larger than primary

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Recovery inconsistencies, standby much larger than primary
Дата
Msg-id CAM-w4HNeVaWwt3-KVi_OF8MHcO1C0iS50RNKad25He0GTGgKDQ@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
On Wed, Feb 12, 2014 at 8:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Oh, wait a minute.  It's not just a matter of whether we find the right
> block: we also have to consider whether XLogReadBufferExtended will
> apply the right "mode" behavior.  Currently, it supposes that all pages
> past the initially observed EOF should be assumed to be uninitialized;
> but if we're working with an inconsistent database, that seems like
> an unsafe assumption.  It might be that a page is there but we've not
> (yet) fixed the length of some preceding segment.  If we want to not
> get bogus "WAL contains references to invalid pages" failures in such
> scenarios, it seems like we need a more invasive change than what
> I just committed.  I think your patch didn't cover this consideration
> either.

Hm. I *think* those cases would be handled anyways since the table
would later be truncated. Arguably any reference after the "short"
segment is a "reference to an invalid page" since it means it's a
record which predates the records which caused the extension.
Obviously it would still give the error in the case we had where files
were missing but then probably it should give errors in that case.

-- 
greg



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Dead code or buggy code?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCH] pg_upgrade: support for btrfs copy-on-write clones