On 2013-08-02 22:25:36 -0400, Alvaro Herrera wrote: > Andres Freund escribió: > > On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote: > > > Alvaro Herrera escribió: > > > > > > > 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. > > > > > > Here's a patch that should fix the problem. Jesse, if you're able to > > > test it, please give it a run and let me know if it works for you. I > > > was able to upgrade an installation containing a problem that should > > > reproduce yours. > > > > Wouldn't it be easier to make pg_upgrade fudge pg_control to have a safe > > NextMultiXactId/Offset using pg_resetxlog? > > I don't understand. pg_upgrade already fudges pg_control to have a safe > next multi, namely the same value used by the old cluster. The reason > to preserve this value is that we must ensure no older value is > consulted in pg_multixact: those might be present in tuples that were > locked in the old cluster. (To be precise, this is the value to set as > oldest multi, not next multi. But of course, the next multi must be > greater than that one.)
I am suggesting to set them to a greater value than in the old cluster, computed so it's guaranteed that they are proper page boundaries. Then the situation described upthread shouldn't occur anymore, right? Greetings, Andres Freund -- Andres Freund 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
