Re: mdnblocks() sabotages error checking in _mdfd_getseg() - Mailing list pgsql-hackers

From Greg Stark
Subject Re: mdnblocks() sabotages error checking in _mdfd_getseg()
Date
Msg-id CAM-w4HNddRKtOCvgfJ0SnWAHBXWKTMEuv9ZtybD1dnpKUt95Ww@mail.gmail.com
Whole thread Raw
In response to Re: mdnblocks() sabotages error checking in _mdfd_getseg()  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Cluster "stuck" in "not accepting commands to avoid wraparound data loss"
Next
From: Jim Nasby
Date:
Subject: Fwd: [GENERAL] pgxs/config/missing is... missing