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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
