Allá vamos.
Muchas gracias a todos gente, muy amables.
El 3 de mayo de 2018, 13:39, Martín Marqués
escribió:
> El 3 de mayo de 2018, 13:13, Alvaro Herrera
> escribió:
> >
> > Entonces lo que sí podría hacer es algo como
> > psql -c "alter system set hot_standby_feedback to on; select
> pg_relo
Entiendo; está buena la alternativa.
Igual, dado que estamos en medio de una migración, probablemente termine
pasando el dump al master hasta que perezca 9.1.
Implementaría soluciones en la línea que me proponen ya para 9.6 así que me
vienen muy bien las sugerencias igual.
El 3 de mayo de 2018, 1
Gracias Martín; es como decís.
El 3 de mayo de 2018, 12:58, Martin Marques
escribió:
> El 03/05/18 a las 09:59, Alvaro Herrera escribió:
> > Federico Pascual escribió:
> >
> >> pg_dump -F c -v -f "$archivo_export" -n "\"$esquema\"" "$dbname"
> >> 1>$archivo_log 2>$archivo_logerr
> >>
> >> Donde
Hola
Una versión ligeramente diferente podría ser:
SELECT pg_size_pretty(SUM(tamanos))
FROM (
SELECT pg_column_size(row(b.*)) as tamanos
FROM (la gran consulta) as b
) AS c;
Un ejemplo para el caso dado:
SELECT pg_size_pretty(SUM(tamanos))
FROM (
SELECT pg_column_size(row(b.*)
Hola Lista
El comportamiento debe ser sincronico: la trasaccion solo se completara
cuando en las 3 tablas se complete la operación (al hacerlo por medio de
triggers )
Hora
El 3 de mayo de 2018, 13:50, Maria Antonieta Ramirez<
marami...@ulsaneza.edu.mx> escribió:
>
> Buena tarde a todos,
>
>
>
Hola nuevamente, creo que pg_size_pretty está de más, ya con las
divisiones /1024 y /1024 lo estas convirtiendo en MB, lo otro que veo es
que usas SUM
¿Estas segura que necesitas esa función de agregado?
Saludos
El 03/05/18 a las 14:41, Maria Antonieta Ramirez escribió:
Cheque lo que me
Buena tarde a todos,
Tengo una duda ojala me puedan apoyar..
Tengo una tabla principal en la que se guarda el contenido de una materia, con
imagenes y demas. Despues de insertar o modificar un registro , hace una copia
del registro en otras dos tablas de respaldo por medio de triggers que se
Cheque lo que me comentaron e hice lo siguiente:
Para obtener el resultado en megas, es correcta mi consulta?
select pg_size_pretty(sum(pg_column_size(descripcion)/1024::numeric)/1024) FROM
educaciondistancia.contenidos_maestria where id = 123
Saludos
De
Hola,
Gracias por contestar...
hice la siguiente consulta para obtener el tamaño de un registro en especifico:
select pg_size_pretty(sum(pg_column_size(descripcion))) FROM
educaciondistancia.contenidos_maestria where id = 1;
y me dio el siguiente resultado:
"2446 bytes"
Hay alguna f
Hola Maria Antonieta, revisa las funciones que estan en
https://www.postgresql.org/docs/9.6/static/functions-admin.html
específicamente pg_column_size, te quedaria algo como
select (pg_column_size(a)/1024::numeric)/1024 as peso_mb from b where
id=100;
saludos
El 03/05/18 a las 14:19, Ma
De: Maria Antonieta Ramirez [mailto:marami...@ulsaneza.edu.mx]
Enviado el: jueves, 3 de mayo de 2018 2:19 p. m.
Para: FORO POSTGRES
Asunto: consulat para saber el tamaño de un registro en megas
Buena tarde a todos!!
Estoy buscando como obtener el tamaño en megas de un registro especifico de
Buena tarde a todos!!
Estoy buscando como obtener el tamaño en megas de un registro especifico de mi
bd , y no encuentro al consulta adecuada.
ejemplo:
Quiero saber cuanto pesa el contenido de mi campo a de la tabla b donde mi id =
1.
Alguien me puede apoyar con sugerencias.
Gracias.
El 3 de mayo de 2018, 13:13, Alvaro Herrera escribió:
>
> Entonces lo que sí podría hacer es algo como
> psql -c "alter system set hot_standby_feedback to on; select pg_reload_conf()"
> pg_dump -Fc ...
> psql -c "alter system set hot_standby_feedback to off; select
> pg_reload_conf()"
>
> Excepto
Martin Marques escribió:
> El 03/05/18 a las 09:59, Alvaro Herrera escribió:
> > Interesante lío. Me pregunto si funcionaría hacer esto
> >
> > PGOPTIONS=--hot_standby_feedback=1 pg_dump -Fc
>
> Eso no va a funcionar ya que hot_standby_feedback requiere un sighup del
> postmaster para applicar
El 03/05/18 a las 09:59, Alvaro Herrera escribió:
> Federico Pascual escribió:
>
>> pg_dump -F c -v -f "$archivo_export" -n "\"$esquema\"" "$dbname"
>> 1>$archivo_log 2>$archivo_logerr
>>
>> Donde las variables son reemplazadas por sus valores correspondientes.
>>
>> El error que aparece en el log
Bárbaro, gente, muchas gracias por la data.
Voy a hacer la propuesta de utilizar los repositorios que me pasas Alvaro;
lamentablemente no es decisión mía.
La verdad es que la versión estable de Debian queda vieja rápidamente y se
vuelve un problema adherir religiosa y dogmáticamente a sus repositor
Hola Gilberto,
gilberto.casti...@etecsa.cu escribió:
> Para apoyar a Alvaro,
>
> Eso pasa en todas las distros y acá alguien tuvo la osadía de decir que los
> paquetes de los repositorios oficiales de PostgreSQL no están debidamente
> probados. Por favor un respeto a esta comunidad que siempre ha
Para apoyar a Alvaro,
Eso pasa en todas las distros y acá alguien tuvo la osadía de decir que
los paquetes de los repositorios oficiales de PostgreSQL no están
debidamente probados. Por favor un respeto a esta comunidad que siempre
ha demostrado su alto grado de compromiso y profesionalidad.
Federico Pascual escribió:
> 2- La utilización de los repositorios oficiales de los Debian (estable) que
> utiliza el área de SO para los servidores.
El PGDG provee repositorios con paquetes de todas las versiones de
Postgres para todas las versiones de Debian. Mira en
https://apt.postgresql.org
Alvaro,
Entiendo. Actualmente estamos migrando las db a 9.6 (de hecho coexisten
ambas infraestructuras).
Hay dos motivos que relentizan bastante este proceso:
1- Que requiere la participación y aprobación de otros (desarrolladores
dispersos en lugares remotos).
2- La utilización de los repositorios
Federico Pascual escribió:
Hola
> Pruebo poner esos parámetros como me proponés (de hecho no sabía que podía
> configurar los parámetros de esta forma "inline").
> Esta configuración tendrá efecto en el primario por más que el comando lo
> tiro en el slave?
Bueno, el parámetro se usa en el st
Si, ello evitaría ese error,
En mi caso tengo varios nodos, te aclaro, dejo pasar pocas query al
master, para ello uso a los esclavos. Es como llego a ese compromiso de
balanceo; si así se le pudiera llamar ;-)))
On 2018-05-03 09:10, Federico Pascual wrote:
Gilberto,
Hola. Gracias por respon
Gilberto,
Hola. Gracias por responder.
Con eso evitaría este error?
Actualmente estoy haciendo el bkup físico en el maestro y el lógico en el
slave. La idea era distribuir la carga.
Saludos.
El 3 de mayo de 2018, 10:02, escribió:
> Hola Federico,
>
> Hasta donde entiendo del tema, en un esquem
Alvaro,
Muchas gracias por responder.
Pruebo poner esos parámetros como me proponés (de hecho no sabía que podía
configurar los parámetros de esta forma "inline").
Esta configuración tendrá efecto en el primario por más que el comando lo
tiro en el slave?
Hay algo que no esté bien en cuanto la fo
Hola Federico,
Hasta donde entiendo del tema, en un esquema master-esclavos, todas la
tarea de mantenimientos las debes hacer en el master, el se encargará de
actualizar sus dependencias.
Saludos,
Gilberto Castillo
On 2018-05-03 08:50, Federico Pascual wrote:
Buenas gente.
Les consulto po
Federico Pascual escribió:
> pg_dump -F c -v -f "$archivo_export" -n "\"$esquema\"" "$dbname"
> 1>$archivo_log 2>$archivo_logerr
>
> Donde las variables son reemplazadas por sus valores correspondientes.
>
> El error que aparece en el log es el siguiente:
>
> 2018-05-02 20:13:39 GMT+3 postgres
Buenas gente.
Les consulto por el siguiente problema.
En un servidor esclavo (síncrono) Postgres 9.1 se realiza un bkup lógico en
forma diaria de distintas dbs y esquemas.
Cada tanto, el bkup de UN esquema en particular (la realización del mismo),
falla.
El comando utilizado para la realización
27 matches
Mail list logo
