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


[pgsql-es-ayuda] Alguna sugerencia para mejorar el tiempo de respuesta de esta consulta

2015-06-01 Por tema jvenegasperu .
La consulta es esta:

 SELECT a.FECHAPROC AS fechaproc,
a.LOCALIDAD AS localidad,
a.URBANIZA AS urbaniza,
a.CALLE AS calle,
a.CLICODFAC AS clicodfac,
a.NOMBRE AS nombre,
a.NROMUNI AS nromuni,
a.MANZCEN AS manzcen,
a.LOTECEN AS lotecen,
a.TS AS ts,
a.EC AS ec,
a.ECA AS eca,
a.ECD AS ecd,
a.TARIFA AS tarifa,
a.CMEDI AS cmedi,
a.CICLO AS ciclo,
b.id,
b.clvmzna,
b.lote,
r.ciclo_comercial AS ciclo_com_gis,
5000 + rd.trazo_id AS carga,
rd.numero AS orden_carga,
row_number() OVER () AS orden_impresion,
count(d.gid) AS gid,
string_agg((to_char(d.horaini::interval, 'HH24:MI'::text) || '-'::text)
|| to_char(d.horafin::interval, 'HH24:MI'::text), ', '::text ORDER BY
d.zona) AS hopdes,
string_agg((d.fechaini::text || '-'::text) || d.fechafin::text, ',
'::text ORDER BY d.zona) AS fechas_inicio_fin,
sum(d.tiempo) AS horas_servicio_horas,
sum(d.tiempo_num) AS horcnt,
CASE
WHEN length(b.id::text)  0 THEN '1-Con Horario'::character
varying
ELSE '2-Sin Horario'::character varying
END AS tienehorario
   FROM unidos a
 LEFT JOIN (cat_lote b
 LEFT JOIN mag_zonas d ON st_contains(d.the_geom, b.geo_punto) AND
d.vigente = 1
 LEFT JOIN (cat_lote e
 LEFT JOIN rut_detalle rd ON rd.gid = e.gid
 JOIN rut_trazo r ON r.trazo_id = rd.trazo_id) ON b.gid = e.gid AND
r.vigente = 1) ON a.CLICODFAC::text = b.id::text
  WHERE date_part('year'::text, a.FECHAPROC) = 2015::double precision
AND a.EC = 1
  GROUP BY a.FECHAPROC, a.LOCALIDAD, a.URBANIZA, a.CALLE,
a.CLICODFAC, a.NOMBRE, a.NROMUNI, a.MANZCEN, a.LOTECEN, a.TS,
a.EC, a.ECA, a.ECD, a.TARIFA, a.CMEDI, a.CICLO, b.id,
b.clvmzna, b.lote, r.ciclo_comercial, rd.trazo_id, rd.numero
  ORDER BY r.ciclo_comercial, rd.trazo_id, rd.numero


En el explain analyze obtengo esto

WindowAgg  (cost=9740706.30..9794981.40 rows=374311 width=230)
(actual time=52168.480..65089.359 rows=1122034 loops=1)
  -  GroupAggregate  (cost=9740706.30..9787495.18 rows=374311
width=230) (actual time=52168.457..62914.819 rows=1122034 loops=1)
Group Key: r.ciclo_comercial, rd.trazo_id, rd.numero,
a.FECHAPROC, a.LOCALIDAD, a.URBANIZA, a.CALLE, a.CLICODFAC,
a.NOMBRE, a.NROMUNI, a.MANZCEN, a.LOTECEN, a.TS, a.EC,
a.ECA, a.ECD, a.TARIFA, a.CMEDI, a.CICLO, b.id, (...)
-  Sort  (cost=9740706.30..9741642.08 rows=374311 width=230)
(actual time=52168.158..53177.792 rows=1122060 loops=1)
  Sort Key: r.ciclo_comercial, rd.trazo_id, rd.numero,
a.FECHAPROC, a.LOCALIDAD, a.URBANIZA, a.CALLE, a.CLICODFAC,
a.NOMBRE, a.NROMUNI, a.MANZCEN, a.LOTECEN, a.TS, a.EC,
a.ECA, a.ECD, a.TARIFA, a.CMEDI, a.CICLO,  (...)
  *Sort Method: external merge  Disk: 266152kB*
  -  Hash Right Join  (cost=150284.12..9706056.56
rows=374311 width=230) (actual time=3495.335..21677.962 rows=1122060
loops=1)
Hash Cond: ((b.id)::text = (a.CLICODFAC)::text)
-  Merge Left Join  (cost=6233.57..9513169.71
rows=269017 width=99) (actual time=78.767..16777.771 rows=269602
loops=1)
  Merge Cond: (b.gid = e.gid)
  -  Nested Loop Left Join
(cost=0.42..9494129.99 rows=269017 width=91) (actual
time=1.008..16366.263 rows=269602 loops=1)
Join Filter: ((d.the_geom 
b.geo_punto) AND _st_contains(d.the_geom, b.geo_punto))
Rows Removed by Join Filter: 35379942
-  Index Scan using cat_lote_pkey on
cat_lote b  (cost=0.42..83873.24 rows=269017 width=59) (actual
time=0.016..406.860 rows=269590 loops=1)
-  Materialize  (cost=0.00..42.42
rows=132 width=902) (actual time=0.000..0.005 rows=132 loops=269590)
  -  Seq Scan on mag_zonas d
(cost=0.00..41.76 rows=132 width=902) (actual time=0.064..0.667
rows=132 loops=1)
Filter: (vigente = 1)
Rows Removed by Filter: 9
  -  Materialize  (cost=6233.15..17834.78
rows=42592 width=16) (actual time=77.755..286.031 rows=101567
loops=1)
-  Merge Join
(cost=6233.15..17728.30 rows=42592 width=16) (actual
time=77.751..263.574 rows=101565 loops=1)
  Merge Cond: (rd.gid = e.gid)
  -  Sort
(cost=6123.95..6230.43 rows=42592 width=16) (actual
time=77.341..91.721 rows=101565 loops=1)
Sort Key: rd.gid
Sort Method: quicksort
Memory: 7833kB
-  Hash Join
(cost=76.55..2848.99 rows=42592 width=16) (actual time=0.992..44.744
rows=101565 loops=1)
  Hash Cond:
(rd.trazo_id = r.trazo_id)
  

[pgsql-es-ayuda] Como conceder privilegios para modificar funciones a mas de un rol?

2015-06-01 Por tema Andres A. Mamani
Hola lista,

Tengo la necesidad de conceder privilegios para modificar ciertas funciones
a mas de un rol.
Vale decir que mas de un usuario tiene que poder modificar ciertas
funciones sin ser dueños de la misma, pero PostgreSql solo permite
modificar la función al dueño.

Alguna sugerencia?

Saludos


Re: [pgsql-es-ayuda] Como conceder privilegios para modificar funciones a mas de un rol?

2015-06-01 Por tema Andres A. Mamani
muchas gracias... y si, considere esa solución, pero tengo problemas con el
usuario que saca el backup.

Al parecer tendré que modificar los privilegios también de ese usuario.

Sería interesante que postgresql tuviera esa flexibilidad como mysql no?

Saludos.

El 1 de junio de 2015, 17:43, raul andrez gutierrez alejo 
rauland...@gmail.com escribió:

 hola.

 que el dueño del función sea un grupo y que los usuarios que necesitan
 modificar la función hagan parte del grupo.

 El 1 de junio de 2015, 16:36, Alvaro Herrera alvhe...@2ndquadrant.com
 escribió:

 Andres A. Mamani escribió:
  Hola lista,
 
  Tengo la necesidad de conceder privilegios para modificar ciertas
 funciones
  a mas de un rol.
  Vale decir que mas de un usuario tiene que poder modificar ciertas
  funciones sin ser dueños de la misma, pero PostgreSql solo permite
  modificar la función al dueño.

 quizás crea un rol que sea el dueño, y luego le otorgas ese rol a los
 roles que necesiten modificar la funció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




 --
 Raul Andres Gutierrez Alejo



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] Como conceder privilegios para modificar funciones a mas de un rol?

2015-06-01 Por tema Alvaro Herrera
Andres A. Mamani escribió:
 Hola lista,
 
 Tengo la necesidad de conceder privilegios para modificar ciertas funciones
 a mas de un rol.
 Vale decir que mas de un usuario tiene que poder modificar ciertas
 funciones sin ser dueños de la misma, pero PostgreSql solo permite
 modificar la función al dueño.

quizás crea un rol que sea el dueño, y luego le otorgas ese rol a los
roles que necesiten modificar la funció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] Como conceder privilegios para modificar funciones a mas de un rol?

2015-06-01 Por tema raul andrez gutierrez alejo
hola.

que el dueño del función sea un grupo y que los usuarios que necesitan
modificar la función hagan parte del grupo.

El 1 de junio de 2015, 16:36, Alvaro Herrera alvhe...@2ndquadrant.com
escribió:

 Andres A. Mamani escribió:
  Hola lista,
 
  Tengo la necesidad de conceder privilegios para modificar ciertas
 funciones
  a mas de un rol.
  Vale decir que mas de un usuario tiene que poder modificar ciertas
  funciones sin ser dueños de la misma, pero PostgreSql solo permite
  modificar la función al dueño.

 quizás crea un rol que sea el dueño, y luego le otorgas ese rol a los
 roles que necesiten modificar la funció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




-- 
Raul Andres Gutierrez Alejo


Re: [pgsql-es-ayuda] Como conceder privilegios para modificar funciones a mas de un rol?

2015-06-01 Por tema Jaime Casanova
2015-06-01 16:57 GMT-05:00 Andres A. Mamani andres.a...@gmail.com:
 muchas gracias... y si, considere esa solución, pero tengo problemas con el
 usuario que saca el backup.


necesitas que el usuario que saca el backup también pueda modificar
la función?


 Sería interesante que postgresql tuviera esa flexibilidad como mysql no?


No, eso es una mala idea. Eso lo haría inseguro.
En todo caso, porque necesitas modificar la función y que varios
usuarios puedan hacerlo? Eso suena a un problema mal resuelto.

-- 
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

-
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