Hola Alvaro
Desarrolle este pequeño script para actualizar en cada base los valores de
datminmxid,
select oid, datminmxid , datname from pg_database;
update pg_database as x
set datminmxid=y.nuevo
from (
select relminmxid as nuevo from pg_class where (cast(cast(relminmxid AS
text) AS bigint))<>0 and (cast(cast(relminmxid AS text) AS bigint))<>1
order by (cast(cast(relminmxid AS text) AS bigint)) asc limit 1
) as y
where x.datname='crm_seguro' and x.oid='16438'::oid;
Está bien? Puedo dejar este valor así? Lo estoy ejecutando y no genera
error sin embargo lo estoy haciendo sobre las bases que se pueden recuperar
fácil de un backup....
🙈🙉🙊
De antemano muchas gracias.. Me surge una duda adicional.. Que mas
debería uno validar? .. A qué me refiero: pues si no se hubiese
presentando el problema seguramente se hubiese presentando después con
peores consecuencias.. Donde se puede revisará o validar los valores
correctos que debe tiene una base en sus diccionario de sistema. Existe
algún script o herramienta que haga este diagnóstico? Muchas gracias
Hellmuth Vargas escribió:
> Hola Alvaro de eso que me escribe (cito) :
>
> "Todos estos son síntomas clásicos de haber actualizado con el pg_upgrade
> de alguna versión entre 9.3.0 y 9.3.4 (inclusive), que dejan el
> datminmxid en 1 (un número que en realidad no es correcto)"
>
> Que debo hacer para subsanarlo? O que implicaciones tiene? Muchas
> gracias!!!
Para corregirlo hay que cambiar los valores de datminmxid en
pg_database. La idea es hacer que apunte al multixact más temprano que
tenga tu sistema; en tu caso será un multixact que esté en el segmento
0008. Tendría que ser algo como
0008 * 32 * 2048
pero me parece que ese valor exacto no sirve, porque es muy probable que
en realidad el multixact de esa ubicación esté apuntando a cero, y si
no me equivoco, eso no serviría. Creo que habría que mirar el archivo
0008 para saber cuál es el primer valor que no es cero (hexdump).
Hmm, quizás un punto de partida para encontrar un valor bueno sea mirar
los pg_class.relminmxid en cada base de datos. Si no has tenido
wraparound de multixact desde que hiciste el pg_upgrade, el mínimo entre
todos esos valores será el valor que necesitas poner en pg_database.
Luego de un tiempo, una combinación de vacuum y checkpoint hará que el
valor de datminmxid que hayas puesto se propague a
pg_control.oldestMultiXid, y una vez que eso haya pasado el WAL-replay
de los checkpoint ocurrirá correctamente sin errores.
La implicancia es que si no lo corriges, el valor quedará apuntando a un
archivo que no existe (pg_multixact/offset/0000) y ocurrirá un error
cuando el 9.4.2/9.3.7 trate de leerlo (esto es lo que te pasó el otro
día, si no entiendo mal).
Si tienes tiempo de experimentar, creo que podría ser buena idea que le
echaras una mirada a las cosas que he mencionado y nos cuentes, a ver si
surge algo útil ...
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
