2010/3/23 Miguel Angel Hernandez Moreno :
> hola compañeros:
>
> Eh estado leyendo un poco sobre la recuperación de datos y resulta que ya
> habia terminado de configurar
> los script y generar la replica, pero resulta ahora que cuando lo aplique a
> la situación real, NO me permite
> recuperar muc
--- El mar, 3/23/10, Cesar Erices escribió:
De: Cesar Erices
Asunto: Re: [pgsql-es-ayuda] Levantar respaldo solo con el directorio DATA
A: "Gabriel Hermes Colina Zambra"
Cc: pgsql-es-ayuda@postgresql.org
Fecha: martes, 23 de marzo de 2010, 01:24 pm
El 23 de marzo de 2010 12:20, Gabriel
hola compañeros:
Eh estado leyendo un poco sobre la recuperación de datos y resulta que ya
habia terminado de configurar
los script y generar la replica, pero resulta ahora que cuando lo aplique a
la situación real, NO me permite
recuperar muchos registros perdidos!!
osea de 120 000 registros que
2010/3/23 Fernando Hevia :
>
>
> Me permito agregar: si no tienes los fuentes y estás condenado a utilizar esa
> aplicación deficiente, podrías reducir su impacto implementando un pool de
> conexiones con hasta 50 conexiones a Postgres (máximo, preferentemente serán
> 20 ó 30) y dejar que sea el
> -Mensaje original-
> De: pgsql-es-ayuda-ow...@postgresql.org
> [mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de
> Jaime Casanova
> Enviado el: Martes, 23 de Marzo de 2010 17:29
> Para: Marcelo Opazo Vivallos
> CC: Alvaro Herrera; jose javier parra sanchez; Postgres Ayuda
> A
2010/3/23 Marcelo Opazo Vivallos :
>
> Nose realmente que haga la aplicacion y como se conecte. Solo es una
> aplicación web, loggeo y almacena datos.
no tienes los fuentes de la aplicación? ese problema lo vas a tener
siempre entonces y una actualización no servirá para eso, no digo que
no lo hag
hola compañeros:
Eh estado leyendo un poco sobre la recuperación de datos y resulta que ya
habia terminado de configurar
los script y generar la replica, pero resulta ahora que cuando lo aplique a
la situación real, NO me permite
recuperar muchos registros perdidos!!
osea de 120 000 registros que
El día 23 de marzo de 2010 15:42, Alvaro Herrera
escribió:
> Marcelo Opazo Vivallos escribió:
>
>> Tal vez es cierto que esos estados IDLE sirvan para que el sistema
>> quede atento a la escucha de nuevas peticiones. Pero en mi caso, por
>> defecto el archivo de conf viene seteado con max_connecti
Marcelo Opazo Vivallos escribió:
> Tal vez es cierto que esos estados IDLE sirvan para que el sistema
> quede atento a la escucha de nuevas peticiones. Pero en mi caso, por
> defecto el archivo de conf viene seteado con max_connections = 100 lo
> tuve que aumentar, ya que se llenaba de los estados
El día 23 de marzo de 2010 14:08, Alvaro Herrera
escribió:
> jose javier parra sanchez escribió:
>> Creo que con este tema estais 'creando' un problema donde no lo hay.
>> Postgresql usa procesos, cada vez que 'algo' se conecta, se crea un
>> proceso, pero al finalizar su tarea no se destruye, est
jose javier parra sanchez escribió:
> Creo que con este tema estais 'creando' un problema donde no lo hay.
> Postgresql usa procesos, cada vez que 'algo' se conecta, se crea un
> proceso, pero al finalizar su tarea no se destruye, esto no es
> necesariamente 'malo', se hace asi porque es menos cost
El 23 de marzo de 2010 12:20, Gabriel Hermes Colina Zambra <
hermeszam...@yahoo.com> escribió:
> Estaba sobre fedora 10 y por falta de experiencia borre
> como root cosas importantes del sistema.
>
> Entre con LiveCd y encontre el directorio DATA intacto.
>
> La version de PostgreSQL 8.4 de 64 bit
Estaba sobre fedora 10 y por falta de experiencia borre
como root cosas importantes del sistema.
Entre con LiveCd y encontre el directorio DATA intacto.
La version de PostgreSQL 8.4 de 64 bit, voy a instalar DEBIAN
y quisiera saber si copiando el directorio DATA, el resto seria transparente.
Lo
Creo que con este tema estais 'creando' un problema donde no lo hay.
Postgresql usa procesos, cada vez que 'algo' se conecta, se crea un
proceso, pero al finalizar su tarea no se destruye, esto no es
necesariamente 'malo', se hace asi porque es menos costoso usar uno de
esos 'procesos' en espera a
Estimada Lista,
Los problemas de IDLE tambien me pasan. He averiguado un poco y
realmente nose si se deba a error de programación del cliente que se
conecta o bien a configuración en el Postgres. Según vi en postgres no
existe ninguna configuración que mate estos procesos zombies superado
ciertos
2010/3/23 Diego Ayala
>
>
> Sin embargo, mis procesos IDLE varian mucho y utilizan mucha memoria, como
> podria hacer para bajar ese consumo por conexion IDLE, ya que no hacen
> nada..??
> La configuracion que tengo es
> shared_buffers=2GB
si tienes 10 GB en ram en un servidor dedicado dale al
El 23 de marzo de 2010 11:41, Jaime Casanova
escribió:
> 2010/3/23 Diego Ayala
> >
> >
> > Sin embargo, mis procesos IDLE varian mucho y utilizan mucha memoria,
> como podria hacer para bajar ese consumo por conexion IDLE, ya que no hacen
> nada..??
> > La configuracion que tengo es
> > shared_bu
Buenos dias, tengo una situacion referente a algunos procesos IDLE de mi
servidor, ya que consumen mucha memoria, por mas que son IDLE, y en teoria,
no hacen nada.. Encontre algo referente a esto en el historial donde Alvaro
indicaba que una conexion que no hace nada ocupa como 3 MB.
mostrar det
Buenas,
Si, actualmente, que yo sepa pgpool recupera el backend entero con todas las
BBDD que contuviera.
Un saludo
El 22 de marzo de 2010 20:31, Miguel Angel Hernandez Moreno <
miguel.hdz@gmail.com> escribió:
> Hola!!!
>
> Bueno te daras cuenta que anteriormente me habia comunicado contigo
Hola gente, encontré en pgFoundry un programa llamado pg_reorg que dice ser
la alternativa a VACUUM FULL y CLUSTER
http://pgfoundry.org/projects/reorg/, ¿alguien que lo haya probado y
tenga alguna opinión al respecto?
gracias.
Sergio.
20 matches
Mail list logo
