Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
От | Andres Freund |
---|---|
Тема | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts |
Дата | |
Msg-id | 20140720200225.GA5974@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
|
Список | pgsql-bugs |
On 2014-07-20 13:37:01 -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > On Tue, Jul 1, 2014 at 03:01:06PM -0400, Alvaro Herrera wrote: > >> Finally, there is the question of what to do if the database has already > >> been upgraded and thus the tables are all at relminmxid=1. As far as I > >> can tell, if the original value of nextMulti was below 2^31, there > >> should be no issue because vacuuming would advance the value normally. > >> If the original value was beyond that point, then vacuum would have been > >> bleating all along about the wraparound point. In this case, I think it > >> should be enough the UPDATE the pg_class values to the current > >> oldestMulti value from pg_control, but I haven't tested this. > > > Well, we are already having users run a query for the 9.3.X minor > > version upgrade to optionally remove the 0000 file. Is there something > > else they should run to test for this? We certainly could check for > > files >= 8000, but I am not sure that is sufficient. We would then need > > them to somehow update all the database/relation minmxid fields, and I > > am not even sure what value we should set it to. Is that something we > > want to publish? > > I started transcribing Bruce's proposed fix procedure at > https://wiki.postgresql.org/wiki/20140702pg_upgrade_fix > into the release notes, but I'm afraid it's all wet. I don't understand why we should do anything but remove the 0000 file if it's all zeroes? This seems far too complicated. Beside the fact that I doubt it's actually achieving anything reliably? > I'm a bit inclined to not say anything about fix procedures in the release > notes, because I'm not sure that this is a problem in the field. If > anybody did have a wraparound they'd be getting bleats from VACUUM, and no > one has reported any such thing that I've heard. There actually have been a couple reports about the general problem I think - reacting to one was how I noticed the bug. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-bugs по дате отправления: