Re: Problemas con pg_dump

Hola a todos.

Tengo una duda que plantear. Posiblemente sea una burrada, pero tengo
que preguntarlo, siguiendo el consejo que me dió un día un maestro (el
que tiene una duda y pregunta, es tonto durante cinco minutos. El que
no lo hace, es tonto para toda la vida).

Se me plantea el caso de dos bases de datos, en el mismo servidor, con
las que necesito trabajar. Lo que necesitaría hacer es copiar
registros de una tabla a otra tabla de otra base de datos. Había
pensado en hacer un trigger que tras un insert haga un insert a la
otra tabla de la otra base de datos.

¿Es posible esto?, ¿alguien ha hecho esto alguna vez?.

Como alternativa, se me había ocurrido hacer un script en consola
(fuera de postgres) que saque los datos que quiero a un archivo
temporal y luego los inserte a la tabla correspondiente. Poniendo la
ejecución de este archivo en el cron o en las tareas programas, en
caso de windows.

Esta última alternativa no me gusta mucho.

Espero su ayuda.

Gracias a todos.

--
Saludos.
Pablo.

El 26/03/08, Pablo Braulio <brulics(at)gmail(dot)com> escribió:
> Hola a todos.
>
> Tengo una duda que plantear. Posiblemente sea una burrada, pero tengo
> que preguntarlo, siguiendo el consejo que me dió un día un maestro (el
> que tiene una duda y pregunta, es tonto durante cinco minutos. El que
> no lo hace, es tonto para toda la vida).
>
> Se me plantea el caso de dos bases de datos, en el mismo servidor, con
> las que necesito trabajar. Lo que necesitaría hacer es copiar
> registros de una tabla a otra tabla de otra base de datos. Había
> pensado en hacer un trigger que tras un insert haga un insert a la
> otra tabla de la otra base de datos.
>
> ¿Es posible esto?, ¿alguien ha hecho esto alguna vez?.
>

Utiliza DBLink para poder realizar eso, pero .... si ambas bases de
datos estan relacionadas de alguna forma es buena idea utilizar la
misma base de datos y separar tus datos (los crrespondientes a la
"base de datos A" en un esquema y los correspondientes a la "base de
datos B" en otro esquema) asi te evitaras problemas mayores.

> Como alternativa, se me había ocurrido hacer un script en consola
> (fuera de postgres) que saque los datos que quiero a un archivo
> temporal y luego los inserte a la tabla correspondiente. Poniendo la
> ejecución de este archivo en el cron o en las tareas programas, en
> caso de windows.
>
> Esta última alternativa no me gusta mucho.
>
> Espero su ayuda.
>
> Gracias a todos.
>

--
"Linux is for people who hate Windows, BSD is for people who love UNIX".
"Social Engineer -> Because there is no patch for human stupidity"
"The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ;
mount ; fsck ; more ; yes ; umount ; sleep."
"Documentation is like sex: when it is good, it is very, very good;
and when it is bad, it is better than nothing."

> Utiliza DBLink para poder realizar eso, pero .... si ambas bases de
> datos estan relacionadas de alguna forma es buena idea utilizar la
> misma base de datos y separar tus datos (los crrespondientes a la
> "base de datos A" en un esquema y los correspondientes a la "base de
> datos B" en otro esquema) asi te evitaras problemas mayores.
>

No sabía que se pueden usar distinto esquemas dentro de una misma base
de datos. Nunca te acostarás sin saber una cosa mas.

El caso es que las dos bases de datos son de dos programas distintos.
No son bases creadas por mi, sino que ya están desarrolladas.

Miraré DBLink, a ver que tal.
--
Saludos.
Pablo.

Pablo Braulio escribió:

> Se me plantea el caso de dos bases de datos, en el mismo servidor, con
> las que necesito trabajar. Lo que necesitaría hacer es copiar
> registros de una tabla a otra tabla de otra base de datos.

Creo que es mas conveniente no poner los datos en distintas bases de
datos, sino mas bien en distintos esquemas. Mira el CREATE SCHEMA y la
variable search_path para que te vayas haciendo una idea.

Si tienes los datos en la misma BD, puedes mantener los datos que
necesitas en ambas BDs en una sola ubicacion, ahorrandote el trabajo de
sincronizacion.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Pablo Braulio escribió:

> El caso es que las dos bases de datos son de dos programas distintos.
> No son bases creadas por mi, sino que ya están desarrolladas.

Y eso que importa?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Hola,
Hace un tiempo que estamos teniendo problemas con los backups, en algunos casos simplemente queda
como si estuviera haciendo un backup pero el archivo deja de crecer.
En otros casos tenemos este error:

pg_dump: dumping contents of table ncdjt00
pg_dump: SQL command failed
pg_dump: Error message from server: se perdió la sincronía con el servidor: se recibió un mensaje
de tipo «3», largo 154284080
pg_dump: The command was: COPY public.ncdjt00 (ncdjemsede, ncdjnume, ncdjemcuit, ncdjafcuil,
ncdjanio, ncdjmes, ncdjgrfa, ncdjnogf, ncdjapor, ncdjupddate, ncdjupduser, ncdjupdtime, ncdjcont,
ncdjapco, ncdjremu) TO stdout;
pg_dump: *** aborted because of error

Estamos con PostgreSQL 8.2.5 on amd64-portbld-freebsd6.2, compiled by GCC cc (GCC) 3.4.6 [FreeBSD]
20060305 y hemos tratado de hacer backups con pg_dump 8.2.5.7260, 8.3.0.7045 y 8.3.0.831

¿Alguna pista de qué puede estar mal?

Gracias
Sebastián

Yahoo! Encuentros.

Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! Encuentros http://yahoo.cupidovirtual.com/servlet/NewRegistration

Sebastián Baioni escribió:
> Hola,
> Hace un tiempo que estamos teniendo problemas con los backups, en algunos casos simplemente queda
> como si estuviera haciendo un backup pero el archivo deja de crecer.
> En otros casos tenemos este error:
>
> pg_dump: dumping contents of table ncdjt00
> pg_dump: SQL command failed
> pg_dump: Error message from server: se perdió la sincronía con el servidor: se recibió un mensaje
> de tipo «3», largo 154284080

Hmm, y ¿hay algo raro en el log del servidor?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alvaro Herrera escribió:
> Pablo Braulio escribió:
>
>> Se me plantea el caso de dos bases de datos, en el mismo servidor, con
>> las que necesito trabajar. Lo que necesitaría hacer es copiar
>> registros de una tabla a otra tabla de otra base de datos.
>
> Creo que es mas conveniente no poner los datos en distintas bases de
> datos, sino mas bien en distintos esquemas. Mira el CREATE SCHEMA y la
> variable search_path para que te vayas haciendo una idea.
>
> Si tienes los datos en la misma BD, puedes mantener los datos que
> necesitas en ambas BDs en una sola ubicacion, ahorrandote el trabajo de
> sincronizacion.
>

No se si estoy entendiendo bien lo que decís. Voy a explicar de lo que
se trata.

Tengo un cliente que usa dos programas:

Dotproject, para la gestión de proyectos: http://www.dotproject.net/
Abanq, para facturación y contabilidad: http://infosial.com/

Ambos programas usan postgresql como bases de datos.

De lo que se trataría es buscar el modo de hacer un enlace en ambos
programas.

Por ejemplo:

Sacar datos de una tabla (de la base de dotproject), mediante un select
y grabarlos en otra tabla de la base de abanq. Por eso preguntaba lo de
DBLINK.

Alvaro. ¿Con tu comentario te refieres ha que haga la instalación de las
dos bases de datos en una misma base de datos, pero con distinto
Schema?. Igual he dicho una burrada. :-P

- --

< ¡¡Nos vemos!! >
----------------------------
\
\
.::!!!!!!!:.
.!!!!!:. .:!!!!!!!!!!!!
~~~~!!!!!!. .:!!!!!!!!!UWWW$$$
:$$NWX!!: .:!!!!!!XUWW$$$$$$$$$P
$$$$$##WX!: .<!!!!UW$$$$" $$$$$$$$#
$$$$$ $$$UX :!!UW$$$$$$$$$ 4$$$$$*
^$$$B $$$$\ $$$$$$$$$$$$ d$$R"
"*$bd$$$$ '*$$$$$$$$$$$o+#"
"""" """""""
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6m8+K7lGsMchFswRAu2vAKCINJxzhE8CXmtB+dME3oe/qiWGjQCcCGun
8C1GJkyHFHI+e8DDAzwWuh0=
=xE4b
-----END PGP SIGNATURE-----

Pablo Braulio escribió:

> Alvaro. ¿Con tu comentario te refieres ha que haga la instalación de las
> dos bases de datos en una misma base de datos, pero con distinto
> Schema?. Igual he dicho una burrada. :-P

Justamente. Para hacer que ambos funcionen independientemente sin
molestarse y sin tener que ser modificados, podrias crear dos usuarios
distintos, uno para cada una. Luego haces
ALTER USER usuario1 SET search_path = 'dotproject'
y cuando esa aplicacion se conecte con ese usuario, solo verá esas
tablas.

Luego cuando la aplicacion abanq quiera ver una tabla de dotproject,
tienes que hacer

select .. from dotproject.tabla_de_la_otra_aplicacion

Si quieres evitar modificar las aplicaciones, tienes algunas
alternativas.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
> Justamente. Para hacer que ambos funcionen independientemente sin
> molestarse y sin tener que ser modificados, podrias crear dos usuarios
> distintos, uno para cada una. Luego haces
> ALTER USER usuario1 SET search_path = 'dotproject'
> y cuando esa aplicacion se conecte con ese usuario, solo verá esas
> tablas.
>
> Luego cuando la aplicacion abanq quiera ver una tabla de dotproject,
> tienes que hacer
>
> select .. from dotproject.tabla_de_la_otra_aplicacion
>
> Si quieres evitar modificar las aplicaciones, tienes algunas
> alternativas.
>

Me gusta la idea. Pero como no tengo experiencia con schemas, voy a
hacer una pregunta:

- - ¿Hay problema que dos tablas o procedimientos (funciones, triggers,
etc) se llamen del mismo modo en cada uno de los schemas?. En tiendo que
no, pues uno sería "schema1.tablaclientes" y el otro
"schema2.tablaclientes". Como no estoy seguro, pregunto.

Gracias por la ayuda.
- --

< ¡¡Nos vemos!! >
----------------------------
\
\
.::!!!!!!!:.
.!!!!!:. .:!!!!!!!!!!!!
~~~~!!!!!!. .:!!!!!!!!!UWWW$$$
:$$NWX!!: .:!!!!!!XUWW$$$$$$$$$P
$$$$$##WX!: .<!!!!UW$$$$" $$$$$$$$#
$$$$$ $$$UX :!!UW$$$$$$$$$ 4$$$$$*
^$$$B $$$$\ $$$$$$$$$$$$ d$$R"
"*$bd$$$$ '*$$$$$$$$$$$o+#"
"""" """""""
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6oK0K7lGsMchFswRAmO5AJ49gxyZW8oB9ym+2gvtWESkSdZnngCgq4Q+
Qzv4aS/hjM53QHIPBIzzfU8=
=TenY
-----END PGP SIGNATURE-----

Pablo Braulio escribió:

> - - ¿Hay problema que dos tablas o procedimientos (funciones, triggers,
> etc) se llamen del mismo modo en cada uno de los schemas?.

No.

> En tiendo que no, pues uno sería "schema1.tablaclientes" y el otro
> "schema2.tablaclientes". Como no estoy seguro, pregunto.

Correcto.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

> > Hola,
> > Hace un tiempo que estamos teniendo problemas con los backups, en algunos casos simplemente
queda como si estuviera haciendo un backup pero el archivo deja de crecer.
> > En otros casos tenemos este error:
> >
> > pg_dump: dumping contents of table ncdjt00
> > pg_dump: SQL command failed
> > pg_dump: Error message from server: se perdió la sincronía con el servidor: se recibió un
mensaje de tipo «3», largo 154284080
>
> Hmm, y ¿hay algo raro en el log del servidor?

En el log del servidor no hay nada raro, solo se ven:
WARNING: there is already a transaction in progress
Y en algunos momentos sale Mar 26 11:24:30 syrha kernel:
collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
Pero el administrador dice que es un tema para mejorar la performance del disco y que nosotros
usamos mirroring.

Los errores aparecen siempre en el cliente, hoy por ejemplo tuvimos otro error:
pg_dump: Falló la extracción del contenido de la tabla «tutut00»: PQgetCopyData() falló.
pg_dump: Mensaje de error del servidor: cannot allocate memory for input buffer

Pero en otros casos se queda como haciendo el backup y el archivo deja de crecer y no tira ningún
error, pero con el pgAdminIII vemos que hay locks de tablas del servidor:
PID DB Relation Mode
5652 si pg_authid AccessShareLock
5652 si pg_proc_proname_args_nsp_index AccessShareLock
5652 si pd_depend_depender_index AccessShareLock
5652 si pg_operator_oprname_l_r_n_index AccessShareLock
5652 si pg_tablespace AccessShareLock
Y así un montón.

Gracias
Sebastián

Yahoo! Encuentros.

Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! Encuentros http://yahoo.cupidovirtual.com/servlet/NewRegistration

Sebastián Baioni escribió:

> Los errores aparecen siempre en el cliente, hoy por ejemplo tuvimos otro error:
> pg_dump: Falló la extracción del contenido de la tabla «tutut00»: PQgetCopyData() falló.
> pg_dump: Mensaje de error del servidor: cannot allocate memory for input buffer

Hmm, esa tabla, ¿tiene alguna columna con valores muy grandes? Prueba a
hacer un "select * from tutut00".

> Pero en otros casos se queda como haciendo el backup y el archivo deja de crecer y no tira ningún
> error, pero con el pgAdminIII vemos que hay locks de tablas del servidor:
> PID DB Relation Mode
> 5652 si pg_authid AccessShareLock
> 5652 si pg_proc_proname_args_nsp_index AccessShareLock
> 5652 si pd_depend_depender_index AccessShareLock
> 5652 si pg_operator_oprname_l_r_n_index AccessShareLock
> 5652 si pg_tablespace AccessShareLock

Eso es normal.

Los registros interesantes en pg_locks son los que tienen granted=false.
Quiere decir que la transaccion a que corresponden esta esperando que
otra transaccion libere el lock.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--- Alvaro Herrera <alvherre(at)commandprompt(dot)com> escribió:
> Sebastián Baioni escribió:
>
> > Los errores aparecen siempre en el cliente, hoy por ejemplo tuvimos otro error:
> > pg_dump: Falló la extracción del contenido de la tabla «tutut00»: PQgetCopyData() falló.
> > pg_dump: Mensaje de error del servidor: cannot allocate memory for input buffer
>
> Hmm, esa tabla, ¿tiene alguna columna con valores muy grandes? Prueba a
> hacer un "select * from tutut00".

Esta tabla tiene 58 campos y ya va por 1.404.523 de registros, un backup de esa tabla pesa 119 MB.
Por lo general se traba en esa tabla y en otras dos que tienen cerca de 5.000.000 de registros,
pero a veces se traba en tablas que solo tienen ciento de registros.

> > Pero en otros casos se queda como haciendo el backup y el archivo deja de crecer y no tira
> ningún
> > error, pero con el pgAdminIII vemos que hay locks de tablas del servidor:
> > PID DB Relation Mode
> > 5652 si pg_authid AccessShareLock
> > 5652 si pg_proc_proname_args_nsp_index AccessShareLock
> > 5652 si pd_depend_depender_index AccessShareLock
> > 5652 si pg_operator_oprname_l_r_n_index AccessShareLock
> > 5652 si pg_tablespace AccessShareLock
>
> Eso es normal.
>
> Los registros interesantes en pg_locks son los que tienen granted=false.
> Quiere decir que la transaccion a que corresponden esta esperando que
> otra transaccion libere el lock.

En nuestro caso siempre está granted=YES

Gracias
Sebastián

Yahoo! Encuentros.

Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! Encuentros http://yahoo.cupidovirtual.com/servlet/NewRegistration

Sebastián Baioni escribió:
>
> --- Alvaro Herrera <alvherre(at)commandprompt(dot)com> escribió:
> > Sebastián Baioni escribió:
> >
> > > Los errores aparecen siempre en el cliente, hoy por ejemplo tuvimos otro error:
> > > pg_dump: Falló la extracción del contenido de la tabla «tutut00»: PQgetCopyData() falló.
> > > pg_dump: Mensaje de error del servidor: cannot allocate memory for input buffer
> >
> > Hmm, esa tabla, ¿tiene alguna columna con valores muy grandes? Prueba a
> > hacer un "select * from tutut00".
>
> Esta tabla tiene 58 campos y ya va por 1.404.523 de registros, un backup de esa tabla pesa 119 MB.
> Por lo general se traba en esa tabla y en otras dos que tienen cerca de 5.000.000 de registros,
> pero a veces se traba en tablas que solo tienen ciento de registros.

La verdad es que no respondiste ninguna de mis preguntas. No quería
saber cuántas columnas tenía, sino si alguna de ellas era muy ancha (por
ej. un texto muy largo o algo así)

Para mí, "trabarse" significa que se detiene en la mitad del trabajo.
Pero arriba dices que se cae con un error. ¿Cuál de las dos es
correcta?

También sería bueno que indicaras si puedes hacer un "select * from
tutut00" y que termine correctamente.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--- Alvaro Herrera <alvherre(at)commandprompt(dot)com> escribió:

> Sebastián Baioni escribió:
> >
> > --- Alvaro Herrera <alvherre(at)commandprompt(dot)com> escribió:
> > > Sebastián Baioni escribió:
> > >
> > > > Los errores aparecen siempre en el cliente, hoy por ejemplo tuvimos otro error:
> > > > pg_dump: Falló la extracción del contenido de la tabla «tutut00»: PQgetCopyData() falló.
> > > > pg_dump: Mensaje de error del servidor: cannot allocate memory for input buffer
> > >
> > > Hmm, esa tabla, ¿tiene alguna columna con valores muy grandes? Prueba a
> > > hacer un "select * from tutut00".
> >
> > Esta tabla tiene 58 campos y ya va por 1.404.523 de registros, un backup de esa tabla pesa 119
> MB.
> > Por lo general se traba en esa tabla y en otras dos que tienen cerca de 5.000.000 de
> registros,
> > pero a veces se traba en tablas que solo tienen ciento de registros.
>
> La verdad es que no respondiste ninguna de mis preguntas. No quería
> saber cuántas columnas tenía, sino si alguna de ellas era muy ancha (por
> ej. un texto muy largo o algo así)
>
> Para mí, "trabarse" significa que se detiene en la mitad del trabajo.
> Pero arriba dices que se cae con un error. ¿Cuál de las dos es
> correcta?
>
> También sería bueno que indicaras si puedes hacer un "select * from
> tutut00" y que termine correctamente.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

Sí, podemos hacer un select * from tutut00, tardó 222.5766 ms y no genera ningún tipo de error.
Los campos más anchos son 10 campos de 30 caracteres cada uno.
A veces da un error de el error:
pg_dump: Falló la extracción del contenido de la tabla «tutut00»: PQgetCopyData() falló.
pg_dump: Mensaje de error del servidor: cannot allocate memory for input buffer
A veces:
pg_dump: Error message from server: se perdió la sincronía con el servidor: se recibió un mensaje
de tipo «3», largo 154284080
pg_dump: The command was: COPY public.ncdjt00 (ncdjemsede, ncdjnume, ncdjemcuit, ncdjafcuil,
ncdjanio, ncdjmes, ncdjgrfa, ncdjnogf, ncdjapor, ncdjupddate, ncdjupduser, ncdjupdtime, ncdjcont,
ncdjapco, ncdjremu) TO stdout;
Y a veces simplemente se traba, deja de crecer el archivo, no arroja ningún error y desde el
pgAdmin III vemos que están muchas tablas del servidor con AccessShareLock
y Grant=YES.

Gracias
Sebastián

Yahoo! Encuentros.

Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! Encuentros http://yahoo.cupidovirtual.com/servlet/NewRegistration