Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
От | Alvaro Herrera |
---|---|
Тема | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts |
Дата | |
Msg-id | 20140619221240.GC27747@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: pg_upgrade < 9.3 -> >=9.3 misses a step around
multixacts
|
Список | pgsql-bugs |
BTW I hacked up pg_resetxlog a bit to make it generate the necessary pg_multixact/offset file when -m is given. This is not acceptable for commit because it duplicates the #defines from pg_multixact.c, but maybe we want this functionality enough that we're interested in a more complete version of this patch; also it unconditionally writes one zero byte to the file, which is of course wrong if the file exists and already contains data. It'd be nice to be able to write this in a way that lets it work for all existing SLRU users (pg_clog is the most common, but pg_multixact/members and the predicate locking stuff might also be useful). Not sure what would that look like. Another consideration is that it doesn't remove existing files that are outside of the new valid range according to freezing parameters and such, but I'm not sure this is really doable considering that we might need to change the relminmxid and datminmxid values, etc. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-bugs по дате отправления: