Right after a fresh initdb on a 9.3 or master database: postgres=# select oid,relname,relminmxid from pg_class where relname='pg_database'; oid | relname | relminmxid ------+-------------+------------ 1262 | pg_database | 4244967297 (1 row) That bogus value seems to appear already some time during initdb. The relminmxid for all other tables is 1, which is correct. - Heikki
Heikki Linnakangas wrote: > Right after a fresh initdb on a 9.3 or master database: > > postgres=# select oid,relname,relminmxid from pg_class where > relname='pg_database'; > oid | relname | relminmxid > ------+-------------+------------ > 1262 | pg_database | 4244967297 > (1 row) > > That bogus value seems to appear already some time during initdb. > The relminmxid for all other tables is 1, which is correct. I finally figured the source of this issue: it's caused by VACUUM FULL (executed by initdb while copying template1 into template0): we're missing a protection that relminmxid doesn't go backwards when swapping heaps. We already have such a check for xids. This is mostly innocuous, but I'm about to push the attached fix all the same, backpatched to 9.3. (The extra context lines make the patch very clear.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера