On 22 May 2012 02:50, Robert Haas <robertmh...@gmail.com> wrote: >> Not very sure why a metapage is better than a catalog table. > > Mostly because there's no chance of the startup process accessing a > catalog table during recovery, but it can read a metapage.
OK, sounds reasonable. Based upon all you've said, I'd suggest that we make a new kind of fork, in a separate file for this, .meta. But we also optimise the VM and FSM in the way you suggest so that we can replace .vm and .fsm with just .meta in most cases. Big tables would get a .vm and .fsm appearing when they get big enough, but that won't challenge the inode limits. When .vm and .fsm do appear, we remove that info from the metapage - that means we keep all code as it is currently, accept for an optimisation of .vm and .fsm when those are small enough to do so. We can watermark data files using special space on block zero using some code to sneak that in when the page is next written, but that is regarded as optional, rather than an essential aspect of an upgrade/normal operation. Having pg_upgrade touch data files is both dangerous and difficult to back out in case of mistake, so I am wary of putting the metapage at block 0. Doing it the way I suggest means the .meta files would be wholly new and can be deleted as a back-out. We can also clean away any unnecessary .vm/.fsm files as a later step. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
