Jesse Denardo escribió:
> $ 9.2_dev/bin/pg_controldata data
> Latest checkpoint's NextMultiXactId: 2982
> Latest checkpoint's NextMultiOffset: 6479
So what's happening here is that the MultiXact 2982 lives in a SLRU page
that doesn't exist. pg_upgrade didn't copy the pg_multixact files from
the old cluster, because they are not compatible; instead it just sets
the values in pg_control. As soon as a new multixact is to be created,
things fail because the code is not prepared to deal with the
possibility that the underlying SLRU files have not been extended during
normal operation.
I see two ways to deal with this:
1. On each multixact creation, verify whether the pages we're trying to
modify do in fact exist. If they don't, create them.
2. At startup, verify the "next" multixact values, and extend the files
if necessary.
I think (1) is not a very good idea because it will cause too large an
impact at runtime, when it is not really necessary. I lean more towards
(2). On IM, Bruce suggested instead:
2a. Same as (2), but only do it in pg_upgrade's usage of postgres'
binary-upgrade mode (postgres -b). Thus this will be done once during
the upgrade process and not every time the system starts up.
As it turns out, I have a patched slru.c that adds a new function to
verify whether a page exists on disk. I created this for the commit
timestamp module, for the BDR branch, but I think it's what we need
here.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services