On 2015-06-02 11:37:02 -0400, Robert Haas wrote: > The exact circumstances under which we're willing to replace a > relminmxid with a newly-computed one that differs are not altogether > clear to me, but there's an "if" statement protecting that logic, so > there are some circumstances in which we'll leave the existing value > intact. I guess we'd have to change that then. > It would similarly do so when the oldest MXID reference in the > relation is in fact 1, but that value can't be vacuumed away yet. I'd thought of just forcing consumption of one multixact in that case. Not pretty, but imo acceptable. > Also, the database might be really big. Even if it were true that a > full scan of every table would get us out of this state, describing > the time that it would take to do that as "relatively short" seems to > me to be considerably understating the impact of a full-cluster > VACUUM. Well. We're dealing with a corrupted cluster. Having a way out that's done automatically, even if it takes a long while, is pretty good already. In many cases the corruption (i.e. pg_upgrade) happened long ago, so the table's relminmxid will already have been recomputed. I think that's acceptable. > With regard to the more general question of WAL-logging this, are you > going to work on that? Are you hoping Alvaro or I will work on that? > Should we draw straws? It seems like somebody needs to do it. I'm willing to invest the time to develop an initial version, but I'll need help evaluating it. I don't have many testing resources available atm, and I'm not going to trust stuff I developed while travelling by just looking at the code. Greetings, Andres Freund -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
