Re: mdnblocks() sabotages error checking in _mdfd_getseg()

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: mdnblocks() sabotages error checking in _mdfd_getseg()
Дата
Msg-id CAM-w4HNddRKtOCvgfJ0SnWAHBXWKTMEuv9ZtybD1dnpKUt95Ww@mail.gmail.com
обсуждение исходный текст
Ответ на Re: mdnblocks() sabotages error checking in _mdfd_getseg()  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Dec 10, 2015 at 7:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I really don't like Robert's proposal of a metapage though.  We've got too
>> darn many forks per relation already.
>
> Oh, I wasn't thinking of adding a fork, just repurposing block 0 of
> the main fork, as we do for some index types.

Not to mention that it should probably be done for all forks. In
practice none of the other forks are going to go over a gigabyte these
days but having different extension logic depending on the fork would
be a pain and only limit future uses of forks.

It doesn't seem like an easy change to make work with binary upgrades
though. I suppose you could just support the metapage being absent in
perpetuity but then it's hard to test and would make the logic in md
even more complex than now rather than simpler.


Incidentally, for comparison Oracle has a header page on every data
file with various information. Data files are added like we add
segments to tables but they are actually pieces of a tablespace rather
than a table. The most significant piece of metadata that they store
in this header block is actually the commit sequence number --
effectively equivalent to our LSN -- that the file is consistent with.
That lets you see how far back you need to start recovery and you can
narrow down which data files actually need recovery.




-- 
greg



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"
Следующее
От: Jim Nasby
Дата:
Сообщение: Fwd: [GENERAL] pgxs/config/missing is... missing