On Thu, Dec 10, 2015 at 7:09 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
