Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-06-02 Por tema Hellmuth Vargas
Hola Alvaro y lista

Como para no perder el impulso y poder definir el procedimiento apropiado
para subsanar el bug y agradeciendo su  tiempo y apoyo, tengo dos
situaciones:

1 Cluster de base de datos PostgreSQL con no muchas transacciones, la
carpeta /opt/PostgreSQL/9.3/data/pg_multixact/offsets/ tiene solo un
archivo ():

[root@mpc1-bd offsets]# ls -lah
total 116K
drwx-- 2 postgres postgres 4,0K feb 12  2014 .
drwx-- 4 postgres postgres 4,0K feb 12  2014 ..
-rw--- 1 postgres postgres 144K jun  1 18:50 



Sobre una de las bases de este cluster ejecuto

SELECT relminmxid FROM pg_class;

lo exporte a cvs y lo cargue en excel para ordenarlo

los 5 primeros son:

0112723157441587615907

Descartando 0 y 1 seleccionaría 12723 y ese debería ser el valor con el que
debo setear en pg_database:

update pg_database set datminmxid='12723'::xid where datname='bd_principal'
and oid='16436'::oid.

antes de ejecutar el UPDATE para validar y/o confirmar hago un  hexdump
del archivo:

[root@mpc100-bd offsets]# hexdump -C  | more
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
||
*
c6c0  00 00 00 00 00 00 00 00  00 00 00 00 01 00 00 00
||
c6d0  03 00 00 00 05 00 00 00  07 00 00 00 09 00 00 00
||
c6e0  0b 00 00 00 0d 00 00 00  0f 00 00 00 11 00 00 00
||
c6f0  13 00 00 00 15 00 00 00  17 00 00 00 19 00 00 00
||
c700  1b 00 00 00 1e 00 00 00  20 00 00 00 23 00 00 00  |
...#...|
c710  25 00 00 00 27 00 00 00  29 00 00 00 2b 00 00 00
|%...'...)...+...|
c720  2d 00 00 00 2f 00 00 00  31 00 00 00 33 00 00 00
|-.../...1...3...|
c730  35 00 00 00 37 00 00 00  39 00 00 00 3b 00 00 00
|5...7...9...;...|
c740  3d 00 00 00 3f 00 00 00  41 00 00 00 43 00 00 00
|=...?...A...C...|
c750  45 00 00 00 47 00 00 00  49 00 00 00 4b 00 00 00
|E...G...I...K...|
c760  4d 00 00 00 4f 00 00 00  51 00 00 00 53 00 00 00
|M...O...Q...S...|
c770  55 00 00 00 57 00 00 00  59 00 00 00 5b 00 00 00
|U...W...Y...[...|
c780  5d 00 00 00 5f 00 00 00  61 00 00 00 63 00 00 00
|]..._...a...c...|
c790  65 00 00 00 67 00 00 00  69 00 00 00 6b 00 00 00
|e...g...i...k...|
c7a0  6d 00 00 00 6f 00 00 00  71 00 00 00 73 00 00 00
|m...o...q...s...|
c7b0  75 00 00 00 77 00 00 00  79 00 00 00 7b 00 00 00
|u...w...y...{...|
c7c0  7d 00 00 00 7f 00 00 00  81 00 00 00 83 00 00 00
|}...|
c7d0  85 00 00 00 87 00 00 00  89 00 00 00 8b 00 00 00
||
c7e0  8d 00 00 00 8f 00 00 00  91 00 00 00 93 00 00 00
||
c7f0  95 00 00 00 97 00 00 00  99 00 00 00 9b 00 00 00
||
c800  9d 00 00 00 9f 00 00 00  a1 00 00 00 a3 00 00 00
||
c810  a5 00 00 00 a7 00 00 00  a9 00 00 00 ab 00 00 00
||
c820  ad 00 00 00 af 00 00 00  b1 00 00 00 b3 00 00 00
||
c830  b5 00 00 00 b7 00 00 00  b9 00 00 00 bb 00 00 00
||
c840  bd 00 00 00 bf 00 00 00  c1 00 00 00 c3 00 00 00
||
c850  c5 00 00 00 c7 00 00 00  c9 00 00 00 cb 00 00 00
||
c860  cd 00 00 00 cf 00 00 00  d1 00 00 00 d3 00 00 00
||
c870  d5 00 00 00 d7 00 00 00  d9 00 00 00 db 00 00 00
||
c880  dd 00 00 00 df 00 00 00  e1 00 00 00 e3 00 00 00
||
c890  e5 00 00 00 e7 00 00 00  e9 00 00 00 eb 00 00 00
||
c8a0  ed 00 00 00 ef 00 00 00  f1 00 00 00 f3 00 00 00
||
c8b0  f5 00 00 00 f7 00 00 00  f9 00 00 00 fb 00 00 00
||
c8c0  fd 00 00 00 ff 00 00 00  01 01 00 00 03 01 00 00
||

más le soy sincero: no sé que debo interpretar del mismo o donde debo ver,
trate de buscar el mismo valor que me arrojo en el paso anterior pero no lo
vi.


2. Cluster de base de datos PostgreSQL con  muchas transacciones, la
carpeta /opt/PostgreSQL/9.3/data/pg_multixact/offsets/ tiene 13 archivos:


[root@Mpc2-bd offsets]# ls -alh
total 3,2M
drwx-- 2 postgres postgres 4,0K may 29 09:39 .
drwx-- 4 postgres postgres 4,0K feb 16  2014 ..
-rw--- 1 postgres postgres 256K mar  4  2014 0008
-rw--- 1 postgres postgres 256K abr  9  2014 0009
-rw--- 1 postgres postgres 256K may 24  2014 000A
-rw--- 1 postgres postgres 256K jul  8  2014 000B
-rw--- 1 postgres postgres 256K ago 19  2014 000C
-rw--- 1 postgres postgres 256K sep 26  2014 000D
-rw--- 1 postgres postgres 256K nov  1  2014 000E
-rw--- 1 postgres postgres 256K dic  5 12:04 000F
-rw--- 1 postgres postgres 256K ene  9 13:29 0010
-rw--- 1 postgres postgres 256K feb 12 14:47 0011
-rw--- 1 postgres postgres 256K mar 25 08:06 0012
-rw--- 1 postgres postgres 256K may  5 12:47 0013
-rw--- 1 postgres postgres 184K jun  2 08:05 0014


Sobre una de las bases de este cluster ejecuto

SELECT relminmxid FROM pg_class;

lo exporte a csv y lo cargue en excel para ordenarlo


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-06-01 Por tema Hellmuth Vargas
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!!!
El may. 30, 2015 1:29 PM, Hellmuth Vargas hiv...@gmail.com escribió:

 Hola Alvaro

 EL listado es el siguiente:

 [root@BD offsets]# ls -lah
 total 3,2M
 drwx-- 2 postgres postgres 4,0K may 26 23:16 .
 drwx-- 4 postgres postgres 4,0K feb 16  2014 ..
 -rw--- 1 postgres postgres 256K mar  4  2014 0008
 -rw--- 1 postgres postgres 256K abr  9  2014 0009
 -rw--- 1 postgres postgres 256K may 24  2014 000A
 -rw--- 1 postgres postgres 256K jul  8  2014 000B
 -rw--- 1 postgres postgres 256K ago 19  2014 000C
 -rw--- 1 postgres postgres 256K sep 26  2014 000D
 -rw--- 1 postgres postgres 256K nov  1  2014 000E
 -rw--- 1 postgres postgres 256K dic  5 12:04 000F
 -rw--- 1 postgres postgres 256K ene  9 13:29 0010
 -rw--- 1 postgres postgres 256K feb 12 14:47 0011
 -rw--- 1 postgres postgres 256K mar 25 08:06 0012
 -rw--- 1 postgres postgres 256K may  5 12:47 0013
 -rw--- 1 postgres postgres 168K may 29 07:39 0014

 El 30 de mayo de 2015, 11:52 a. m., Alvaro Herrera
 alvhe...@2ndquadrant.com escribió:

 Hellmuth Vargas escribió:

  El mensaje de error siempre era:
 
  _2015-05-29 09:19:53 COTproc:5371 ERROR:  could not access status
 of transaction 1
  _2015-05-29 09:19:53 COTproc:5371 DETAIL:  Could not open file
 pg_multixact/offsets/: No existe el fichero o el directorio.

 OK.

  Pues como ya les anuncie, no cuento con la version 9.3.7, por lo tanto
 los
  siguientes resultados son de la versión 9.3.6, espero que les puedan
 servir:
 
  select oid, datminmxid from pg_database:
 
   oid datminmxid  238079085 1  12896 1  12891 1155162  16416 1  16417 1
  16424 1  269582566 775213  276879078 775213  16426 1  16418 1  16420 1
  239906595 1  16419 1  1 1124837  302106991 1124837  16421 1  16422 1
  286765847 1069569  302181511 1124837
 
   /opt/PostgreSQL/9.3/bin/pg_controldata  /opt/PostgreSQL/9.3/data/

  Latest checkpoint's oldestMultiXid:   1
  Latest checkpoint's oldestMulti's DB: 16421

 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).

 ¿Qué archivos tienes en  /opt/PostgreSQL/9.3/data/pg_multixact/offset ?

 --
 Álvaro Herrerahttp://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services




 --
 Cordialmente,

 Ing. Hellmuth I. Vargas S.
 Esp. Telemática y Negocios por Internet
 Oracle Database 10g Administrator Certified Associate
 EnterpriseDB Certified PostgreSQL 9.3 Associate




Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-06-01 Por tema Hellmuth Vargas
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/) 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 Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-06-01 Por tema Alvaro Herrera
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/) 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 Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-06-01 Por tema Alvaro Herrera
Hellmuth Vargas escribió:
 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í?

Ni idea.  ¿por qué no muestras un select oid, relminmxid from pg_class
where relminmxid  '0', a ver si tiene sentido?  El problema es que si
has consumido una gran cantidad de multixacts, podrían haber valores que
estén pasados el punto medio de wraparound, o haber dado la vuelta
completa, y las comparaciones normales  y  podrían no tener sentido ...

 Lo estoy ejecutando y no genera error sin embargo lo estoy haciendo
 sobre las bases que se pueden recuperar fácil de un backup

Me parece sensato!

 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.. 

Bueno, a algunos ya se les presentaron con peores consecuencias.  En
realidad, el bug de ahora surgió a partir de la corrección de un bug más
serio que causaba pérdidas de datos en ciertos casos.  Para saber más
habría que darle una mirada al pg_controldata y el listado de archivos
en pg_multixact/offset, y ver si son consistentes.

 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?

No tenemos nada aún.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-30 Por tema Alvaro Herrera
Hellmuth Vargas escribió:

 El mensaje de error siempre era:
 
 _2015-05-29 09:19:53 COTproc:5371 ERROR:  could not access status of 
 transaction 1
 _2015-05-29 09:19:53 COTproc:5371 DETAIL:  Could not open file 
 pg_multixact/offsets/: No existe el fichero o el directorio.

OK.

 Pues como ya les anuncie, no cuento con la version 9.3.7, por lo tanto los
 siguientes resultados son de la versión 9.3.6, espero que les puedan servir:
 
 select oid, datminmxid from pg_database:
 
  oid datminmxid  238079085 1  12896 1  12891 1155162  16416 1  16417 1
 16424 1  269582566 775213  276879078 775213  16426 1  16418 1  16420 1
 239906595 1  16419 1  1 1124837  302106991 1124837  16421 1  16422 1
 286765847 1069569  302181511 1124837
 
  /opt/PostgreSQL/9.3/bin/pg_controldata  /opt/PostgreSQL/9.3/data/

 Latest checkpoint's oldestMultiXid:   1
 Latest checkpoint's oldestMulti's DB: 16421

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).

¿Qué archivos tienes en  /opt/PostgreSQL/9.3/data/pg_multixact/offset ?

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-30 Por tema Hellmuth Vargas
Hola Alvaro

EL listado es el siguiente:

[root@BD offsets]# ls -lah
total 3,2M
drwx-- 2 postgres postgres 4,0K may 26 23:16 .
drwx-- 4 postgres postgres 4,0K feb 16  2014 ..
-rw--- 1 postgres postgres 256K mar  4  2014 0008
-rw--- 1 postgres postgres 256K abr  9  2014 0009
-rw--- 1 postgres postgres 256K may 24  2014 000A
-rw--- 1 postgres postgres 256K jul  8  2014 000B
-rw--- 1 postgres postgres 256K ago 19  2014 000C
-rw--- 1 postgres postgres 256K sep 26  2014 000D
-rw--- 1 postgres postgres 256K nov  1  2014 000E
-rw--- 1 postgres postgres 256K dic  5 12:04 000F
-rw--- 1 postgres postgres 256K ene  9 13:29 0010
-rw--- 1 postgres postgres 256K feb 12 14:47 0011
-rw--- 1 postgres postgres 256K mar 25 08:06 0012
-rw--- 1 postgres postgres 256K may  5 12:47 0013
-rw--- 1 postgres postgres 168K may 29 07:39 0014

El 30 de mayo de 2015, 11:52 a. m., Alvaro Herreraalvhe...@2ndquadrant.com
escribió:

 Hellmuth Vargas escribió:

  El mensaje de error siempre era:
 
  _2015-05-29 09:19:53 COTproc:5371 ERROR:  could not access status
 of transaction 1
  _2015-05-29 09:19:53 COTproc:5371 DETAIL:  Could not open file
 pg_multixact/offsets/: No existe el fichero o el directorio.

 OK.

  Pues como ya les anuncie, no cuento con la version 9.3.7, por lo tanto
 los
  siguientes resultados son de la versión 9.3.6, espero que les puedan
 servir:
 
  select oid, datminmxid from pg_database:
 
   oid datminmxid  238079085 1  12896 1  12891 1155162  16416 1  16417 1
  16424 1  269582566 775213  276879078 775213  16426 1  16418 1  16420 1
  239906595 1  16419 1  1 1124837  302106991 1124837  16421 1  16422 1
  286765847 1069569  302181511 1124837
 
   /opt/PostgreSQL/9.3/bin/pg_controldata  /opt/PostgreSQL/9.3/data/

  Latest checkpoint's oldestMultiXid:   1
  Latest checkpoint's oldestMulti's DB: 16421

 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).

 ¿Qué archivos tienes en  /opt/PostgreSQL/9.3/data/pg_multixact/offset ?

 --
 Álvaro Herrerahttp://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services




-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-30 Por tema Hellmuth Vargas
Hola Alvaro


El mensaje de error siempre era:

_2015-05-29 09:19:53 COTproc:5371 ERROR:  could not access status of
transaction 1
_2015-05-29 09:19:53 COTproc:5371 DETAIL:  Could not open file
pg_multixact/offsets/: No existe el fichero o el directorio.
_2015-05-29 20:20:27 COTproc:38182 DETAIL:  Could not open file
pg_multixact/offsets/: No existe el fichero o el directorio.
_2015-05-29 20:23:47 COTproc:38740 DETAIL:  Could not open file
pg_multixact/offsets/: No existe el fichero o el directorio.
_2015-05-29 20:29:07 COTproc:39665 DETAIL:  Could not open file
pg_multixact/offsets/: No existe el fichero o el directorio.
_2015-05-29 20:41:18 COT@bd_cll72b@postgres@[local]@proc:37221 DETAIL:
 Could not open file pg_multixact/offsets/: No existe el fichero o el
directorio.
_2015-05-29 20:41:56 COTproc:41876 DETAIL:  Could not open file
pg_multixact/offsets/: No existe el fichero o el directorio.
_2015-05-29 20:44:34 COTproc:45790 DETAIL:  Could not open file
pg_multixact/offsets/: No existe el fichero o el directorio.


con las siguientes sentencias:

VACUUM database:
 vacuum full verbose analyze  tabla;
update tabla2 set...
transaction 1



Pues como ya les anuncie, no cuento con la version 9.3.7, por lo tanto los
siguientes resultados son de la versión 9.3.6, espero que les puedan servir:

select oid, datminmxid from pg_database:

 oid datminmxid  238079085 1  12896 1  12891 1155162  16416 1  16417 1
16424 1  269582566 775213  276879078 775213  16426 1  16418 1  16420 1
239906595 1  16419 1  1 1124837  302106991 1124837  16421 1  16422 1
286765847 1069569  302181511 1124837



 /opt/PostgreSQL/9.3/bin/pg_controldata  /opt/PostgreSQL/9.3/data/
pg_control version number:937
Catalog version number:   201306121
Database system identifier:   5980861421293698031
Database cluster state:   in production
pg_control last modified: sáb 30 may 2015 04:55:50 COT
Latest checkpoint location:   B99/62CE5020
Prior checkpoint location:B99/61090E70
Latest checkpoint's REDO location:B99/6260CE80
Latest checkpoint's REDO WAL file:00010B990062
Latest checkpoint's TimeLineID:   1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:  0/1004521331
Latest checkpoint's NextOID:  302505916
Latest checkpoint's NextMultiXactId:  1355388
Latest checkpoint's NextMultiOffset:  1767491
Latest checkpoint's oldestXID:806796687
Latest checkpoint's oldestXID's DB:   16422
Latest checkpoint's oldestActiveXID:  1004521331
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 16421
Time of latest checkpoint:sáb 30 may 2015 04:53:44 COT
Fake LSN counter for unlogged rels:   0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline:   0
Backup start location:0/0
Backup end location:  0/0
End-of-backup record required:no
Current wal_level setting:hot_standby
Current max_connections setting:  810
Current max_prepared_xacts setting:   0
Current max_locks_per_xact setting:   64
Maximum data alignment:   8
Database block size:  8192
Blocks per segment of large relation: 131072
WAL block size:   8192
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index:  32
Maximum size of a TOAST chunk:1996
Date/time type storage:   64-bit integers
Float4 argument passing:  by value
Float8 argument passing:  by value
Data page checksum version:   0


Cualquier otra cosa con mucho gusto.


El 29 de mayo de 2015, 11:06 p. m., Alvaro Herreraalvhe...@2ndquadrant.com
escribió:

 Hellmuth Vargas escribió:

 Hola,

  Finalmente me toco devolverme a la version 9.3.6, pues al  efectuar las
  rutinas de mantenimiento nocturno (VACUUM) volvió a presentarse el
  problema, muchas gracias a todos por su ayuda.

 Gracias por reportar.

 Por favor, si tienes, indica más detalles de lo que sucedió exactamente
 (mensajes de error, qué archivos faltaban, la salida de pg_controldata,
 y select oid, datminmxid from pg_database).  Todavía se están
 discutiendo los bugs en pgsql-hackers y puede ser útil contar con tu
 caso para verificar los parches propuestos.

 --
 Álvaro Herrerahttp://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services




-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-29 Por tema Alvaro Herrera
Hellmuth Vargas escribió:
 Hola lista
 
 Realice la actualización de la versión 9.3.5 a la versión 9.3.7 en los
 servidores que tengo..  Todo estuvo bien incluso al otro día entre las
 cuestiones rutinarias (creación de indices y cargues de información)
 actualice el film factor de una tabla de alta actualización pero que
 actualiza solo unos pequeños campos,  realizando el procedimiento sugerido:
 
 ALTER TABLE tabla SET (fillfactor=95);
 VACUUM FULL ANALYZE VERBOSE tabla;
 
 Y salió sin problemas
 
 Hoy voy a revisar las estadísticas de la tabla y a practicar nuevamente un
 VACUUM sobre la misma y me sale este error:
 
 ROR:  could not access status of transaction 1
 DETAIL:  Could not open file pg_multixact/offsets/: No existe el
 fichero o el directorio.

Vuelve a 9.3.6 inmediatamente.  Es un bug en 9.3.7 y 9.4.2 que se va a
intentar corregir lo más pronto posible.


-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-29 Por tema Hellmuth Vargas
Hola Alvaro

Y no es posible que copia los archivos faltantes ? O que implicaciones
adicionales puede haber.?  Para devolverme solo podría en la madrugada..
No puedo afecta la disponibilidad en este momento.  Mil gracias
El may. 29, 2015 8:56 AM, Alvaro Herrera alvhe...@2ndquadrant.com
escribió:

 Hellmuth Vargas escribió:
  Hola lista
 
  Realice la actualización de la versión 9.3.5 a la versión 9.3.7 en los
  servidores que tengo..  Todo estuvo bien incluso al otro día entre las
  cuestiones rutinarias (creación de indices y cargues de información)
  actualice el film factor de una tabla de alta actualización pero que
  actualiza solo unos pequeños campos,  realizando el procedimiento
 sugerido:
 
  ALTER TABLE tabla SET (fillfactor=95);
  VACUUM FULL ANALYZE VERBOSE tabla;
 
  Y salió sin problemas
 
  Hoy voy a revisar las estadísticas de la tabla y a practicar nuevamente
 un
  VACUUM sobre la misma y me sale este error:
 
  ROR:  could not access status of transaction 1
  DETAIL:  Could not open file pg_multixact/offsets/: No existe el
  fichero o el directorio.

 Vuelve a 9.3.6 inmediatamente.  Es un bug en 9.3.7 y 9.4.2 que se va a
 intentar corregir lo más pronto posible.


 --
 Álvaro Herrerahttp://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services



Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-29 Por tema Hellmuth Vargas
Hola Alvaro y lista

Pues ya copie los archivos faltantes y ejecute el VACUUM y funcionó
bien, tengo la duda si programar otra ventana y devolverme a la 9.3.6 o
esperar a la 9.3.8 ya con cabeza fría. Muchas gracias por la atención.
El may. 29, 2015 9:31 AM, Alvaro Herrera alvhe...@2ndquadrant.com
escribió:

 Hellmuth Vargas escribió:
  Hola Alvaro
 
  Y no es posible que copia los archivos faltantes ? O que implicaciones
  adicionales puede haber.?  Para devolverme solo podría en la madrugada..
  No puedo afecta la disponibilidad en este momento.  Mil gracias

 Si no te aproblema eso, supongo que es una estrategia válida.  Pero
 en cuanto salga 9.3.8 deberías actualizar.

 --
 Álvaro Herrerahttp://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services



Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-29 Por tema Hellmuth Vargas
Hola Lista


Finalmente me toco devolverme a la version 9.3.6, pues al  efectuar las
rutinas de mantenimiento nocturno (VACUUM) volvió a presentarse el
problema, muchas gracias a todos por su ayuda.

El 29 de mayo de 2015, 9:54 a. m., Hellmuth Vargashiv...@gmail.com
escribió:

 Hola Alvaro y lista

 Pues ya copie los archivos faltantes y ejecute el VACUUM y funcionó
 bien, tengo la duda si programar otra ventana y devolverme a la 9.3.6 o
 esperar a la 9.3.8 ya con cabeza fría. Muchas gracias por la atención.
 El may. 29, 2015 9:31 AM, Alvaro Herrera alvhe...@2ndquadrant.com
 escribió:

 Hellmuth Vargas escribió:
  Hola Alvaro
 
  Y no es posible que copia los archivos faltantes ? O que implicaciones
  adicionales puede haber.?  Para devolverme solo podría en la madrugada..
  No puedo afecta la disponibilidad en este momento.  Mil gracias

 Si no te aproblema eso, supongo que es una estrategia válida.  Pero
 en cuanto salga 9.3.8 deberías actualizar.

 --
 Álvaro Herrerahttp://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services




-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-29 Por tema Alvaro Herrera
Hellmuth Vargas escribió:
 Hola Alvaro
 
 Y no es posible que copia los archivos faltantes ? O que implicaciones
 adicionales puede haber.?  Para devolverme solo podría en la madrugada..
 No puedo afecta la disponibilidad en este momento.  Mil gracias

Si no te aproblema eso, supongo que es una estrategia válida.  Pero
en cuanto salga 9.3.8 deberías actualizar.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-22 Por tema Álvaro Hernández Tortosa


On 22/05/15 20:37, Enrique Escobar wrote:


Yo si recibo mas de 15 por dia, pregunto yo cual seria el mejor 
proceso para subir de la 9.0 que es la que tengo en producción a la 
9.3. ya lo hemos intentado y me marca errores que no son compatibles, 
(saben de algún link para subir).




En todo caso, 9.0 no sufre, aparentemente, este problema, podrías 
actualizar sólo a 9.0.20 (lo cual es compatible a nivel binario). Sin 
embargo, 9.0 deja de estar soportado en septiembre.si puedes 
permitirte (tiempo de parada, tamaño de bbdd) un dump/reload, es lo más 
fácil para actualizar a 9.3.


Saludos,

Álvaro


--
Álvaro Hernández Tortosa


---
8Kdata




/Gracias/

/Enrique Escobar/

*De:*pgsql-es-ayuda-ow...@postgresql.org 
[mailto:pgsql-es-ayuda-ow...@postgresql.org] *En nombre de *Javier 
Lugo Porras

*Enviado el:* viernes, 22 de mayo de 2015 11:49
*Para:* Álvaro Hernández Tortosa; pgsql-es-ayuda@postgresql.org
*Asunto:* [pgsql-es-ayuda] version 9.3.5_ actualizar?

Alvaro, buen dia, ya lo lei el email de david page,
yo estoy usando la version 9.3.5, no se si deba hacer ese update._?
es un cliente pequeño no maneja esos valores de 1 millon de 
transacciones diarias...

hasta ahora no he visto inconvenientes...
que recomienas__?

Javier Lugo Porras
www.multe-commerce http://www.multe-commerce Inc.


On 05/22/2015 10:33 a.m., Álvaro Hernández Tortosa wrote:

Hola a todos.

Seguramente muchos lo habréis visto ya, pero por si no es el
caso: hoy se han liberado las versiones 9.4.2, 9.3.7, 9.2.11,
9.1.16 y 9.0.20 de PostgreSQL. Contienen numerosas correcciones
menores, algunos fallos de seguridad probablemente no muy
importantes y sólo para las versiones 9.3 y 9.4 (anteriores no
están afectadas) la corrección de un grave fallo, con potencial
corrupción o pérdida de datos.

Se recomienda a todos los usuarios de 9.3 y 9.4 planificar una
actualización a la menor brevedad posible.

Adjunto al correo y os doy el enlace
(http://files.meetup.com/10534562/20150522-Actualizacion_PostgreSQL.pdf)
al anuncio realizado hoy, en español, para completar esta
información.

Espero que os resulte de utilidad a todos esta información y
podáis planificar las actualizaciones de vuestros PostgreSQL lo
antes posible.

Saludos,

Álvaro




-

Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org  
mailto:pgsql-es-ayuda@postgresql.org)

Para cambiar tu suscripción:

http://www.postgresql.org/mailpref/pgsql-es-ayuda





Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-22 Por tema Alvaro Herrera
Álvaro Hernández Tortosa escribió:
 
 On 22/05/15 20:37, Enrique Escobar wrote:
 
 Yo si recibo mas de 15 por dia, pregunto yo cual seria el mejor proceso
 para subir de la 9.0 que es la que tengo en producción a la 9.3. ya lo
 hemos intentado y me marca errores que no son compatibles, (saben de algún
 link para subir).
 
 En todo caso, 9.0 no sufre, aparentemente, este problema, podrías
 actualizar sólo a 9.0.20 (lo cual es compatible a nivel binario). Sin
 embargo, 9.0 deja de estar soportado en septiembre.si puedes permitirte
 (tiempo de parada, tamaño de bbdd) un dump/reload, es lo más fácil para
 actualizar a 9.3.

Los problemas de multixact se introdujeron en 9.3, así que ninguna
versión desde 9.0 hasta 9.2 está afectada.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda


RE: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-22 Por tema Enrique Escobar
Yo si recibo mas de 15 por dia, pregunto yo cual seria el mejor proceso para
subir de la 9.0 que es la que tengo en producción a la 9.3. ya lo hemos
intentado y me marca errores que no son compatibles, (saben de algún link
para subir). 

 

Gracias

Enrique Escobar

 

De: pgsql-es-ayuda-ow...@postgresql.org
[mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de Javier Lugo Porras
Enviado el: viernes, 22 de mayo de 2015 11:49
Para: Álvaro Hernández Tortosa; pgsql-es-ayuda@postgresql.org
Asunto: [pgsql-es-ayuda] version 9.3.5_ actualizar?

 

Alvaro, buen dia, ya lo lei el email de david page,
yo estoy usando la version 9.3.5, no se si deba hacer ese update._?
es un cliente pequeño no maneja esos valores de 1 millon de transacciones
diarias...
hasta ahora no he visto inconvenientes...
que recomienas__?

Javier Lugo Porras
www.multe-commerce Inc.


On 05/22/2015 10:33 a.m., Álvaro Hernández Tortosa wrote:

Hola a todos. 

Seguramente muchos lo habréis visto ya, pero por si no es el caso: hoy
se han liberado las versiones 9.4.2, 9.3.7, 9.2.11, 9.1.16 y 9.0.20 de
PostgreSQL. Contienen numerosas correcciones menores, algunos fallos de
seguridad probablemente no muy importantes y sólo para las versiones 9.3 y
9.4 (anteriores no están afectadas) la corrección de un grave fallo, con
potencial corrupción o pérdida de datos. 

Se recomienda a todos los usuarios de 9.3 y 9.4 planificar una actualización
a la menor brevedad posible. 

Adjunto al correo y os doy el enlace
(http://files.meetup.com/10534562/20150522-Actualizacion_PostgreSQL.pdf) al
anuncio realizado hoy, en español, para completar esta información. 

Espero que os resulte de utilidad a todos esta información y podáis
planificar las actualizaciones de vuestros PostgreSQL lo antes posible. 

Saludos, 

Álvaro 






-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

 



RE: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-22 Por tema Gilberto Castillo


 Yo si recibo mas de 15 por dia, pregunto yo cual seria el mejor proceso
 para
 subir de la 9.0 que es la que tengo en producción a la 9.3. ya lo hemos
 intentado y me marca errores que no son compatibles, (saben de algún link
 para subir).


Mis paso:
=

Sin usar pg_upgrade.

Tomo una salva de 9.0 con dumpall de 9.3, luego restauro con el pg_restore
de 9.3 en el nuevo servidor.

Listo

Saludos,
Gilberto Castillo
ETECSA, La Habana, Cuba
--- 
This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at 
host imx3.etecsa.cu
Visit our web-site: http://www.kaspersky.com, http://www.viruslist.com
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-22 Por tema Alvaro Herrera
Enrique Escobar escribió:
 Yo si recibo mas de 15 por dia, pregunto yo cual seria el mejor proceso para
 subir de la 9.0 que es la que tengo en producción a la 9.3. ya lo hemos
 intentado y me marca errores que no son compatibles, (saben de algún link
 para subir). 

pg_upgrade requiere que algunas opciones de compilación de la versión
nueva sean iguales que las de la versión antigua.  Si te marca errores
de incompatibilidad, lo que debes hacer es ajustar las opciones a
configure y recompilar.  Si quieres reportar los errores en detalle que
te arroja, te podemos guiar.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda


Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-22 Por tema Álvaro Hernández Tortosa


On 22/05/15 18:48, Javier Lugo Porras wrote:

Alvaro, buen dia, ya lo lei el email de david page,
yo estoy usando la version 9.3.5, no se si deba hacer ese update._?
es un cliente pequeño no maneja esos valores de 1 millon de 
transacciones diarias...

hasta ahora no he visto inconvenientes...
que recomienas__?


Yo recomendaría actualizar a 9.3.7, sin duda. El problema es 
importante, y aunque pudiera ser improbable en el caso de tu cliente 
(que tampoco hay garantías) es buena práctica. Revisa las release notes 
también de 9.3.6 por si hubiera algún proceso post-instalación que 
aplicara a tu caso. Si no, basta con hacer una breve parada, actualizar 
binarios y re-arrancar. No suele ser un grave problema en muchos entornos.


Saludos,

Álvaro


--
Álvaro Hernández Tortosa


---
8Kdata





Javier Lugo Porras
www.multe-commerce Inc.


On 05/22/2015 10:33 a.m., Álvaro Hernández Tortosa wrote:

Hola a todos.

Seguramente muchos lo habréis visto ya, pero por si no es el 
caso: hoy se han liberado las versiones 9.4.2, 9.3.7, 9.2.11, 9.1.16 
y 9.0.20 de PostgreSQL. Contienen numerosas correcciones menores, 
algunos fallos de seguridad probablemente no muy importantes y sólo 
para las versiones 9.3 y 9.4 (anteriores no están afectadas) la 
corrección de un grave fallo, con potencial corrupción o pérdida de 
datos.


Se recomienda a todos los usuarios de 9.3 y 9.4 planificar una 
actualización a la menor brevedad posible.


Adjunto al correo y os doy el enlace 
(http://files.meetup.com/10534562/20150522-Actualizacion_PostgreSQL.pdf) 
al anuncio realizado hoy, en español, para completar esta información.


Espero que os resulte de utilidad a todos esta información y podáis 
planificar las actualizaciones de vuestros PostgreSQL lo antes posible.


Saludos,

Álvaro



-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda






Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

2015-05-22 Por tema Alvaro Herrera
Álvaro Hernández Tortosa escribió:
 
 On 22/05/15 18:48, Javier Lugo Porras wrote:
 Alvaro, buen dia, ya lo lei el email de david page,
 yo estoy usando la version 9.3.5, no se si deba hacer ese update._?
 es un cliente pequeño no maneja esos valores de 1 millon de transacciones
 diarias...
 
 Yo recomendaría actualizar a 9.3.7, sin duda. El problema es importante,
 y aunque pudiera ser improbable en el caso de tu cliente (que tampoco hay
 garantías) es buena práctica. Revisa las release notes también de 9.3.6 por
 si hubiera algún proceso post-instalación que aplicara a tu caso. Si no,
 basta con hacer una breve parada, actualizar binarios y re-arrancar. No
 suele ser un grave problema en muchos entornos.

En realidad la cantidad de transacciones diarias no es importante.  Lo
que sí importa es cuántos multixact usas, y más concretamente qué tan
grande es cada multixact en promedio.  Si tus multixact en promedio son
pequeños (que es lo normal) no es probable que el bug te afecte.  De
todas maneras, lo más seguro es actualizar.

Para saber el tamaño de tus multixact, toma un pg_controldata hoy (t1) y
otro en una semana más (t2).  Resta los valores de nextMultiXactId y
nextMultiXactOffset; divide las diferencias, es decir

next offset t2 - next offset t1
---  = tamaño promedio
 next multi t2 - next multi t1

Estarás en problemas si el tamaño promedio es mayor que
UINT32 / multixact max freeze age

Ahora, como dice mi tocayo, es fácil actualizar y se corrigen otros
problemas también.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda