Re: Que se debe tener en cuenta para migrar de versión postgres 9.4.5 a 9.6.3

[Daymel Bonne]

El 4 de agosto de 2017, 14:01, mauricio pullabuestan<jmaurici...@yahoo.es>
escribió:

> Buen día.
>
> En producción tenemos PostgreSQL 9.4.5 on x86_64-unknown-linux-gnu,
> compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55), 64-bit sobre un
> servidor ubuntu 16.04, que viene funcionando bien. Estamos pensando a pasar
> a PostgreSQL 9.6.3 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit para actualizarnos y
> aprovechar algo de la PostgreSQL 9.6.3
>
> Para probar tengo una maquina virtual con UBUNTU SERVER 16.04, con
> PostgreSQL 9.6.3 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit, en la cual restaure una
> copia de la base de datos, probando algunas aplicaciones funcionan bien sin
> problemas, no usamos nada especial, solamente funciones, triggers, json,
> crosstab, seriales, funciones de ventana y los clásicos dml
>
> Este ambiente es el correcto para probar el correcto funcionamiento de
> Postgresq 9.6.3 con las aplicaciones,
>


Sólo cuando hayas probado TODAS las funcionalidades de tus aplicaciones
usando la nueva versión de postgres podrás hacer la actualización.



> es decir solo basta con restaurar la base de datos en postgresql 9.6.3
> para poder aprovechar sus mejoras.?
>


Sólo con usar la versión 9.6 ya tienes la ventaja de contar con las muchas
optimizaciones de funcionamiento realizadas en las versiones 9.5 y 9.6. Por
otro lado hay algunas funcionalidades agregadas al SQL que para utilizarlas
tendrás que cambiar las consultas para utilizarlas (en caso que necesites
de esas nuevas funcionalidades), ej:

INSERT . . . ON CONFLICT DO NOTHING/UPDATE
GROUPING SETS, CUBE and ROLLUP

Te sugiero que veas los siguientes links:

https://wiki.postgresql.org/wiki/NewIn96
http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.5


> Existe alguna configuración o compatibilidad entre 9.4.5 y 9.6.3 a tomar
> en cuenta antes para migrar?
>
> Cual es la manera correcta para hacer una actualización de postgresql
> 9.4.5 a 9.6.3 sobre ubuntu server 16.04?
>
>
Hay varias opciones, pg_upgrade, pglogical, pg_dump/pg_restore, slony, etc.
Tendrás que evaluar cuál es el mejor camino para ti.

Saludos


-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: pg_upgrade

[Daymel Bonne]

Hola:

Ubuntu tiene un comando llamado pg_upgradecluster para actualizar que te
abstrae de todo. Este comando usa a su vez pg_upgrade para realizar todo el
trabajo sucio. Yo recomendaría que lo utilices. Aunque es bueno saber como
funcionan las cosas ;)

Saludos


El 6 de septiembre de 2017, 15:06, Eduardo Morras<emorr...@yahoo.es>
escribió:

> On Wed, 6 Sep 2017 16:56:15 + (UTC)
> mauricio pullabuestan <jmaurici...@yahoo.es> wrote:
>
> > Tengo una maquina virtual con ubuntu server 16.04 64 bits con
> > postgresql 9.4 puerto 5432 y postgresql 9.6 puerto 5433 para hacer
> > pruebas de pg_upgrade.
> >
> > Estoy apoyándome en este link para
> > https://gist.github.com/edib/f9965ff37df9828016658ef329c9792a
> >
> >
> > Al momento de hacer
> > sudo su - postgres -c '/usr/lib/postgresql/9.6/bin/pg_upgrade
> > -b /usr/lib/postgresql/9.4/bin -B /usr/lib/postgresql/9.6/bin \
> > -d /var/lib/postgresql/9.4/main/ -D /var/lib/postgresql/9.6/main/ \-o
> > "-c config_file=/etc/postgesql/9.4/main/postgresql.conf" -O "-c
> > config_file=/etc/postgresql/9.6/main/postgresql.conf" --link'
> >
> >
> > tengo un error "invalid option --"
> >
> > No se a que se refiere el error, los path son los correctos, puede
> > decirme donde esta el error?
>
> Creo que se está haciendo un poco de lio con las comillas, además, los
> '-c' de las opciones (-o y -O) no me suenan de nada, hay que usar -o
> /etc/postgesql/9.4/main/postgresql.conf sin más.
>
> Prueba a usar -k en vez de --link.
>
> Para evitar problemas, yo, haria el sudo a postgres y luego el comando
> pg_upgrade.
>
> %sudo su - postgres
> %pg_upgrade.. .
>
> Sin comillas de distintos tipos. Ten en cuenta que el uso de --link o
> -k, hara que postgres9.4 NO pueda volver a levantar tus bd
> actualizadas, haz un backup antes o puedes perderlo todo. Si no pones
> --link o -k, los datos serán copiados a los directorios de 9.6, por lo
> que debes vigilar no quedarte sin sitio en el disco.
>
> > SaludosMauricio.
> >
>
> L Saludos
>
> ---   ---
> Eduardo Morras <emorr...@yahoo.es>
>
>


-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: [MASSMAIL] Replicación Hot-Standby, volver al servidor Maestro a su configuración normal o hacer el servidor esclavo servidor principal

[Daymel Bonne]

El 26 de septiembre de 2017, 16:51, mauricio pullabuestan<
jmaurici...@yahoo.es> escribió:

> Hola Daymel.
>
> Gracias por las recomendaciones, voy a revisar la documentación.
>
> Estoy comenzando con la replicación y me apoye un un manual, donde se
> cambian pocos parámetros
>
> Maestro postgresql.conf
>
> listen_addresses = 'miip'
> wal_level = hot_standby
> synchronous_commit=local
> archive_mode = on
> archive_command = 'cp %p /var/lib/pstgresql/9.6/main/archive/%f'
> max_wal_senders = 2
> wal_keep_segments = 10
> synchronous_standby_names = 'pgslave1'
>
>
>
> Esclavo postgresql.conf
> listen_addresses = 'miip'
> wal_level = hot_standby
> synchronous_commit=local
> max_wal_senders = 2
> wal_keep_segments = 10
> synchronous_standby_names = 'pgslave1'
> hot_standby = on
>
>
>
> Me preocupa quedarme sin espacio en el disco, el directorio archive del
> maestro a crecido 5 gb en un día
>
No se si es automática la limpieza de los archivos wal?
>

No es casualidad que crezca si configuraste que el servidor archive en ese
directorio.


>
> Donde puede ver si estoy usando slot y si es así como lo borro? o como
> puedo mantenerlo en un tamaño razonable?
>

Con la consulta:
SELECT * from pg_replication_slots;

ver replication slots
<https://www.postgresql.org/docs/9.6/static/warm-standby.html#STREAMING-REPLICATION-SLOTS>
en la documentación oficial.


>
> Estoy en busca de un curso, el próximo que se dicta en mi país sobre
> replicación es en unos meses, espero poder asistir, entre tanto necesito
> aprender a hacer esto, espero puedas apoyar.
>

Suerte

Saludos



>
> Saludos.
> Mauricio
>
>
> El Martes 26 de septiembre de 2017 10:45, Daymel Bonne <
> daymel.bo...@2ndquadrant.ec> escribió:
>
>
> Hola Mauricio:
>
> El 26 de septiembre de 2017, 08:55, Gilberto Castillo<gilberto.castillo@
> etecsa.cu> escribió:
>
>
> > Tengo 2 servidores con ubunto server 16.04 y postgresql 9.6 a los cuales
> > se los configuro como maestro y esclavo para replicación hot standby, al
> > momento todo parece estar bien.
> >
> > La configuración se realizo en los archivos postgresql.conf y
> pg_hba.conf,
> > se configuro UFW para ssh y postgresql así como la creación del usuario
> > para la replicación y la copia de la data del servidor maestro.
> > En caso de que algo funcionara mal en el servidor maestro, volverlo al
> > estado antes de la replica bastaría con restaurar los archivos
> > postgresql.conf y pg_hba.conf y reiniciar el servicio de postgres? O se
> > tendría que realizar otro proceso?
>
>
> Sólo remueve la línea del pg_hba.conf donde configuraste el permiso de
> conexión del servidor réplica y haz luego un reload. No tienes que volver a
> reiniciar el servidor maestro. El único paso adicional que pudieras hacer,
> SI es que replicas usando un slot de replicación, es borrarlo, ya que si no
> lo haces, el maestro retendrá wals, y puede llenarte el disco.
>
>
> > Para el servidor esclavo.Al ser de solo lectura y si por alguna razón
> > necesito hacerlo servidor principal, cual seria los pasos para hacerlo?
> > Al momento necesito saber hacerlo manualmente, próximamente voy a probar
> > repmgr
>
>
> Básicamente hay dos formas de hacer que el esclavo se promueva a maestro.
> Puedes promover mediante pg_ctl promote -D data_dir o  touch trigger_file.
> En la documentación se describe que pasa cuando se promueve y explican con
> más detalles, ver la documentacion
> <https://www.postgresql.org/docs/current/static/warm-standby-failover.html>
> .
>
> Recomiendo mucho utilizar repmgr <https://www.repmgr.org/>. Te abstrae de
> muchas cosas en el camino que puedes no tomar en cuenta en caso de una
> promoción de un esclavo, además de que puedes crear notificaciones y
> ejecutar scripts para hacer lo que quieras cuando ocurra el failover.
>
> Saludos
>
> --
> Daymel Bonne   https://www.2ndQuadrant.com/
> <https://www.2ndquadrant.com/>
> Database Consultant, Training & Services
>
>
>
>
>


-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: [MASSMAIL] Replicación Hot-Standby, volver al servidor Maestro a su configuración normal o hacer el servidor esclavo servidor principal

[Daymel Bonne]

Hola Mauricio:

El 26 de septiembre de 2017, 08:55, Gilberto Castillo<
gilberto.casti...@etecsa.cu> escribió:

>
> > Tengo 2 servidores con ubunto server 16.04 y postgresql 9.6 a los cuales
> > se los configuro como maestro y esclavo para replicación hot standby, al
> > momento todo parece estar bien.
> >
> > La configuración se realizo en los archivos postgresql.conf y
> pg_hba.conf,
> > se configuro UFW para ssh y postgresql así como la creación del usuario
> > para la replicación y la copia de la data del servidor maestro.
> > En caso de que algo funcionara mal en el servidor maestro, volverlo al
> > estado antes de la replica bastaría con restaurar los archivos
> > postgresql.conf y pg_hba.conf y reiniciar el servicio de postgres? O se
> > tendría que realizar otro proceso?
>

Sólo remueve la línea del pg_hba.conf donde configuraste el permiso de
conexión del servidor réplica y haz luego un reload. No tienes que volver a
reiniciar el servidor maestro. El único paso adicional que pudieras hacer,
SI es que replicas usando un slot de replicación, es borrarlo, ya que si no
lo haces, el maestro retendrá wals, y puede llenarte el disco.


> > Para el servidor esclavo.Al ser de solo lectura y si por alguna razón
> > necesito hacerlo servidor principal, cual seria los pasos para hacerlo?
> > Al momento necesito saber hacerlo manualmente, próximamente voy a probar
> > repmgr
>

Básicamente hay dos formas de hacer que el esclavo se promueva a maestro.
Puedes promover mediante pg_ctl promote -D data_dir o  touch trigger_file.
En la documentación se describe que pasa cuando se promueve y explican con
más detalles, ver la documentacion
<https://www.postgresql.org/docs/current/static/warm-standby-failover.html>.

Recomiendo mucho utilizar repmgr <https://www.repmgr.org/>. Te abstrae de
muchas cosas en el camino que puedes no tomar en cuenta en caso de una
promoción de un esclavo, además de que puedes crear notificaciones y
ejecutar scripts para hacer lo que quieras cuando ocurra el failover.

Saludos

-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: Replicación Hot Standby

[Daymel Bonne]

El 22 de agosto de 2017, 13:54, mauricio pullabuestan<jmaurici...@yahoo.es>
escribió:

> Buen día
>
> Estoy probando replicación, para ello tengo 2 maquinas virtuales con
> Ubuntu server 16.04 y Postgres 9.6, me apoye en este link
>
> https://www.howtoforge.com/tutorial/how-to-set-up-master-
> slave-replication-for-postgresql-96-on-ubuntu-1604/
>
> Por las pruebas que hice funciona sin problemas.
>
> Postgres 9.6 tiene varias formas de replicar.
>
> Que tipo replicación recomiendan para este ambiente de trabajo.
>
> Servidor Maestro
>
> Servidor HP proliant DL160 gen9, 32 gb memoria, 1 procesador xeon 1.6, 2
> discos (no tengo la velocidad)
>
> Ubuntu Server 16.04, Postgresql 9.6
>
>
> Servidor Esclavo
>
> Servidor HP proliant ML110 gen9, 32 gb memoria, 1 procesador xeon 3.5, 2
> discos (no tengo la velocidad)
>
> Ubuntu Server 16.04, Postgresql 9.6
>
>
> Usuarios concurrentes 40 a 50
>
> Insert 8 a 9 al día
>
> Update 4 al día
>
> Base de datos aproximadamente 20 gb.
>
> La configuración de Postgres no tiene nada especial.
>
>
> Que software puedo utilizar para monitorear que la replicación este
> trabajando?
>
> En la replicación Hot Standby el servidor esclavo es solo de lectura, si
> por alguna razón el servidor Maestro se cae, como puedo promover el
> servidor esclavo para lectura escritura?
>
> Gracias por su ayuda.
> Mauricio
>
>
Hola Mauricio:

Puedes utilizar este esquema:

Aplicativo -> pgbouncer -> PostgreSQL y utiizar repmgr para el failover.

http://www.repmgr.org/

Existen varias herramientas con las que puedes monitorear los servidores.
Icinga, Zabbix son alguna de estas.

Saludos

Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: Replicación Hot Standby

[Daymel Bonne]

Hola Mauricio:

El 24 ago. 2017 8:26 a. m., "mauricio pullabuestan" 
escribió:

Hola Stephen y Daymel.

Gracias por la recomendación.

En cuanto a el tipo de replicación que estoy usando creen que es la
recomendada?


Si lo usas para solo lectura, si.


Pueden facilitarme algún link si es en español mejor o ejemplo de repmgr.


No creo que haya mejor documentación que el mismo sitio de repmgr. Tal vez
sea útil traducirla.


Daymael, estoy comenzando con la replicación y el ambiente linux, pgbouncer
suena bien estaría por probarlo luego la replicación y el repmgr.

En cuando a software para monitorear servidores voy a ver Icinga


Chévere.

Saludos

Re: Postgresql problema !!!

[Daymel Bonne]

Hola Angelo:

El 19 de diciembre de 2017, 11:52, Angelo Astorga<angeloasto...@gmail.com>
escribió:

> Hola lista,
> Desde un momento a otro la cpu del servidor se fue a 100%, donde gran
> parte de este consumo lo absorve postgresql. Desconozco que paso, dado que
> el mismo día x la mañana el servidor y sus recursos andaban como avión y
> ahora solamente al subir servicio postgresql, comienzan las cpu a irse al
> 100%, haciendo inoperante el sistema.
> Plataforma centos + php + postgresql.
>
> Pensamos q eran los discos del raid pero estan bien, luego corrupcion bd y
> como tal, volvimos a montar y sigue igual.
>
> Alguien habrá pasado x esta experiencia q me pueda orientar para descubrir
> causa del problema?
>

Deberás hacer un top, y ver el pid del proceso de postgres que está
consumiendo mucho CPU.
Luego en postgres ejecutar:

select * from pg_stat_activity where pid = ;

Esto te dirá que actividad está consumiendo CPU.

Si es una consulta la causante del problema, puedes matarla con:

SELECT pg_terminate_backend(pid);

Si no es una consulta, das muy poca información para poder ayudar.

Saludos


> Saludos y gracias.
>



-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: [MASSMAIL]Postgresql problema !!!

[Daymel Bonne]

No nos dices si es una consulta, vacuum o algo más. Esa es la información
relevante.

Saludos

El 20 dic. 2017 1:05 p.m., "Angelo Astorga" <angeloasto...@gmail.com>
escribió:

> Hola Daymel,
> Me pediste que vía comando top revisara proceso que consume cpu, eso hice
> y el proceso esta asociados con el postmaster, aplique comando vinculado
> con el pid del proceso
> select * from pg_stat_activity where pid = ;
>
> y hace mención a una tabla que posee 2 millones de registro, lo cual no
> veo nada extraño en ello.
>
>
> Por lo tanto, ahora como saber si el postgresql esta operando normalmente,
> para no tener que instalar nuevamente el servidor desde cero?
>
> saludos,
>
>
> El 20 de diciembre de 2017, 14:53, Daymel Bonne <
> daymel.bo...@2ndquadrant.ec> escribió:
>
>> Hola Angelo:
>>
>> El 20 dic. 2017 11:46 a.m., "Angelo Astorga" <angeloasto...@gmail.com>
>> escribió:
>>
>> Ahora que sacamos el servidor de producción, lo estoy revisando y a
>> simple vista funciona normal.
>> realice la prueba sugerida por el colega Daymel y acusa id del postmaster
>> de una tabla que posee más de 2 millones de registro.
>>
>>
>> Por mi parte no entiendo cuando te refieres a, "acusa id del postmaster
>> de una tabla que posee más de 2 millones de registro".
>>
>> Saludos
>>
>>
>> Como saber si el postgresql esta operando normalmente, para no tener que
>> instalar nuevamente el servidor desde cero?
>>
>> saludos,
>>
>>
>> El 19 de diciembre de 2017, 22:59, Jaime Casanova <
>> jaime.casan...@2ndquadrant.com> escribió:
>>
>>> 2017-12-19 13:13 GMT-05:00 Angelo Astorga <angeloasto...@gmail.com>:
>>> > Hola Lista,
>>> > Dada la lectura de vuestras respuestas, cumplo con complementar
>>> información
>>> > solicitada.
>>> > Linux RH 4.4.7-3 64 bits  +  Postgresql Ver. 8.4.18 64 bits
>>>
>>> En serio?!
>>>
>>> Sabías que RH 4.4 perdió soporte hace más de 7 años?
>>> https://access.redhat.com/support/policy/updates/errata
>>>
>>> y postgresql 8.4 hace 3 años
>>> https://www.postgresql.org/support/versioning/
>>>
>>> y claro, seguimos esperando el resultado de lo que pidió Daymel.
>>> Adicional a eso, podrías ejecutar "mpstat -P ALL 1 >
>>> /tmp/consumo_cpu.txt" en una ventana aparte levantar el servicio de
>>> postgres y dejar que vaya el CPU al 100% luego terminas el comando
>>> mpstat y nos adjuntas el archivo resultante también.
>>>
>>> --
>>> Jaime Casanova  www.2ndQuadrant.com
>>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>>
>>
>>
>>
>

Re: [MASSMAIL]Postgresql problema !!!

[Daymel Bonne]

Hola Angelo:

El 20 dic. 2017 11:46 a.m., "Angelo Astorga" 
escribió:

Ahora que sacamos el servidor de producción, lo estoy revisando y a simple
vista funciona normal.
realice la prueba sugerida por el colega Daymel y acusa id del postmaster
de una tabla que posee más de 2 millones de registro.


Por mi parte no entiendo cuando te refieres a, "acusa id del postmaster de
una tabla que posee más de 2 millones de registro".

Saludos


Como saber si el postgresql esta operando normalmente, para no tener que
instalar nuevamente el servidor desde cero?

saludos,


El 19 de diciembre de 2017, 22:59, Jaime Casanova <
jaime.casan...@2ndquadrant.com> escribió:

> 2017-12-19 13:13 GMT-05:00 Angelo Astorga :
> > Hola Lista,
> > Dada la lectura de vuestras respuestas, cumplo con complementar
> información
> > solicitada.
> > Linux RH 4.4.7-3 64 bits  +  Postgresql Ver. 8.4.18 64 bits
>
> En serio?!
>
> Sabías que RH 4.4 perdió soporte hace más de 7 años?
> https://access.redhat.com/support/policy/updates/errata
>
> y postgresql 8.4 hace 3 años
> https://www.postgresql.org/support/versioning/
>
> y claro, seguimos esperando el resultado de lo que pidió Daymel.
> Adicional a eso, podrías ejecutar "mpstat -P ALL 1 >
> /tmp/consumo_cpu.txt" en una ventana aparte levantar el servicio de
> postgres y dejar que vaya el CPU al 100% luego terminas el comando
> mpstat y nos adjuntas el archivo resultante también.
>
> --
> Jaime Casanova  www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

Re: Consulta sobre Barman

[Daymel Bonne]

El 27 de abril de 2018, 12:17, Daymel Bonne<daymel.bo...@2ndquadrant.ec>
escribió:

> Hola Stephen:
>
> 2018-04-27 10:18 GMT-05:00 Stephen Amell <stephenam...@inbox.lv>:
>
>> Buenos días lista, como va?
>>
>> Estoy empezando a probar Barman 2.3 (http://docs.pgbarman.org/rele
>> ase/2.3/), pero estoy teniendo un problema con una base LATIN1. Mas
>> abajo les dejo el log a ver si me pueden orientar, por lo pronto me estoy
>> uniendo al grupo de barman a ver si ahi encuentro algo (pero es en ingles
>> ;P)
>>
>> ¿Alguien sabe si hay alguna limitación con los diccionarios que respalda
>> barman?
>>
>>
>> 2018-04-27 11:48:04,547 [16909] barman.cli ERROR: 'ascii' codec can't
>> encode character u'\xab' in position 455: ordinal not in range(128)
>> See log file for more details.
>>
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/barman/cli.py", line 1123, in
>> main
>> p.dispatch(pre_call=global_config)
>>   File "/usr/lib/python2.7/site-packages/argh/helpers.py", line 55, in
>> dispatch
>> return dispatch(self, *args, **kwargs)
>>   File "/usr/lib/python2.7/site-packages/argh/dispatching.py", line 174,
>> in dispatch
>> for line in lines:
>>   File "/usr/lib/python2.7/site-packages/argh/dispatching.py", line 277,
>> in _execute_command
>> for line in result:
>>   File "/usr/lib/python2.7/site-packages/argh/dispatching.py", line 231,
>> in _call
>> result = function(namespace_obj)
>>   File "/usr/lib/python2.7/site-packages/barman/cli.py", line 215, in
>> backup
>> server.backup()
>>   File "/usr/lib/python2.7/site-packages/barman/server.py", line 989, in
>> backup
>> self.backup_manager.backup()
>>   File "/usr/lib/python2.7/site-packages/barman/backup.py", line 369, in
>> backup
>> msg_lines = str(e).strip().splitlines()
>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xab' in
>> position 455: ordinal not in range(128)
>>
>> 2018-04-27 11:49:02,101 [17847] barman.config DEBUG: Including
>> configuration file: vm-latin1.cx.ar.conf
>> 2018-04-27 11:49:02,101 [17845] barman.config DEBUG: Including
>> configuration file: latin1.cx.ar.conf
>> 2018-04-27 11:49:02,102 [17847] barman.cli DEBUG: Initialised Barman
>> version 2.3 (config: /etc/barman.conf, args: {'debug': False, 'command':
>> 'cron', 'quiet': True, 'format': 'console'})
>>
>> Esto es un issue conocido que se solucionará en la próxima versión. La
> solución temporal es la siguiente:
>
> Modifica en el fichero /usr/lib/python2.7/site-packages/barman/cli.py  la
> función main y al principio de la función haz el cambio siguiente:
>
> def main(): try: reload(sys) sys.setdefaultencoding('utf8') except: pass #
> ... el resto de la función main aqui
>
>  Saludos
>

Si soluciona, déjanos saber.

Saludos
-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: Consulta sobre Barman

[Daymel Bonne]

Hola Stephen:

2018-04-27 10:18 GMT-05:00 Stephen Amell <stephenam...@inbox.lv>:

> Buenos días lista, como va?
>
> Estoy empezando a probar Barman 2.3 (http://docs.pgbarman.org/release/2.3/),
> pero estoy teniendo un problema con una base LATIN1. Mas abajo les dejo el
> log a ver si me pueden orientar, por lo pronto me estoy uniendo al grupo de
> barman a ver si ahi encuentro algo (pero es en ingles ;P)
>
> ¿Alguien sabe si hay alguna limitación con los diccionarios que respalda
> barman?
>
>
> 2018-04-27 11:48:04,547 [16909] barman.cli ERROR: 'ascii' codec can't
> encode character u'\xab' in position 455: ordinal not in range(128)
> See log file for more details.
>
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/barman/cli.py", line 1123, in
> main
> p.dispatch(pre_call=global_config)
>   File "/usr/lib/python2.7/site-packages/argh/helpers.py", line 55, in
> dispatch
> return dispatch(self, *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/argh/dispatching.py", line 174,
> in dispatch
> for line in lines:
>   File "/usr/lib/python2.7/site-packages/argh/dispatching.py", line 277,
> in _execute_command
> for line in result:
>   File "/usr/lib/python2.7/site-packages/argh/dispatching.py", line 231,
> in _call
> result = function(namespace_obj)
>   File "/usr/lib/python2.7/site-packages/barman/cli.py", line 215, in
> backup
> server.backup()
>   File "/usr/lib/python2.7/site-packages/barman/server.py", line 989, in
> backup
> self.backup_manager.backup()
>   File "/usr/lib/python2.7/site-packages/barman/backup.py", line 369, in
> backup
> msg_lines = str(e).strip().splitlines()
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xab' in
> position 455: ordinal not in range(128)
>
> 2018-04-27 11:49:02,101 [17847] barman.config DEBUG: Including
> configuration file: vm-latin1.cx.ar.conf
> 2018-04-27 11:49:02,101 [17845] barman.config DEBUG: Including
> configuration file: latin1.cx.ar.conf
> 2018-04-27 11:49:02,102 [17847] barman.cli DEBUG: Initialised Barman
> version 2.3 (config: /etc/barman.conf, args: {'debug': False, 'command':
> 'cron', 'quiet': True, 'format': 'console'})
>
> Esto es un issue conocido que se solucionará en la próxima versión. La
solución temporal es la siguiente:

Modifica en el fichero /usr/lib/python2.7/site-packages/barman/cli.py  la
función main y al principio de la función haz el cambio siguiente:

def main(): try: reload(sys) sys.setdefaultencoding('utf8') except: pass #
... el resto de la función main aqui

 Saludos



-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: Replicacion con diferentes versiones

[Daymel Bonne]

Hola:

El 16 de mayo de 2018, 11:28, Kernel<jucab...@gmail.com> escribió:

> Hola,
>
> Siempre he montado la replicacion con versiones iguales, pero
>
> ¿puedo montar un sistema de replicacion con diferentes versiones de
> postgresql?
>
> Por ejemplo maestro la 9.1 y esclavo la 9.2
>

No. Para replicar entre dos versiones diferentes necesitarías 9.4 mínimo,
utilizando pglogical. Por cierto, estás utilizando una versión fuera de
todo soporte y la otra al finalizar en Septiembre del 2018.

https://www.postgresql.org/support/versioning/

Saludos

>
> Gracias
>



-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: Sobre instalacion de pgadmin4

[Daymel Bonne]

Marcos Michel:

Se vale leer la documentación antes. Por otro lado aquí un procedimiento
para hacer lo que quieres. Pero siempre la documentación oficial es lo
mejor.

http://yallalabs.com/linux/how-to-install-pgadmin-4-in-server-mode-as-web-application-on-centos-7-rhel-7/

El lun., 30 abr. 2018 3:32 p.m., Marcos Michel Martinez Perez <
mmartin...@uci.cu> escribió:

> alguien posee alguna guia personal que contenga el proceso de
> instalacion de pgadmin4 ?
>
> UCIENCIA 2018: III Conferencia Científica Internacional de la Universidad
> de las Ciencias Informáticas.
> Del 24-26 de septiembre, 2018 http://uciencia.uci.cu http://eventos.uci.cu
>
>

Re: Consulta de tabla con millones de registros

[Daymel Bonne]

El 29 ene. 2018 3:18 p.m., "Lazaro Garcia"  escribió:

Buenas tardes tengan todos.



Recientemente estoy trabajando en un sistema donde se tendrá una tabla que
puede contener millones de tuplas, por encima de los 50 millones y el
propósito de la tabla será almacenar precios de un producto por día para
cada uno de los clientes existentes. Sobre la tabla se ejecutarán más
lecturas que escrituras y las lecturas deben ser bien rápidas.



Me podrían dar algún consejo sobre como diseñar este problema.

Todo sistema es un caso particular. No das muchos datos para ayudar. En
principio el correcto uso de índices, apoyado de un análisis de las
consultas que se ejecutarán sobre la tabla ayudaría.

El uso de una base NoSQL podría ayudarme en algo?


Sin comentarios.


No es posible utilizar particionado de datos.


Si esto no es posible ya comenzaron mal y deberías revisar el porqué no es
posible hacerlo. Imagino que sea por alguna limitación en el diseño de tu
sistema o alguna tecnología que estén usando. En cualquier caso, es una
limitación importante tendiendo en cuenta las nuevas funcionalidades que
trae Postgres 10 en el tema de particionado de tablas, y las importantes
mejoras que tendrá en la versión 11.



Saludos a todos.

Re: Ayuda con Array

[Daymel Bonne]

Hola:

Puedes ver en la documentación oficial en este enlace:
https://www.postgresql.org/docs/current/static/functions-array.html

En concreto es la función array_length.

Saludos


El 29 ene. 2018 3:34 p.m., "Ovidio Jimenez"  escribió:

Saludos a todos.


Como puedo saber cuantos elementos tengo en el array para que sea el limite
de la sentencia FOR.

/**

 for x in 1..10 loop

Ejemplo  for x in 1..*N* loop

**/


CREATE OR REPLACE FUNCTION insertar_detalle(*_articulo *integer[],
_cantidad numeric[],_precio numeric[])
  RETURNS void AS
$BODY$ declare x integer;
begin

*for x in 1..10 loop*

insert into detalle(codiarti, cantidad, precio) values ($1[x],$2[x],$3[x]);
end loop;
end;
$BODY$ LANGUAGE plpgsql;



Gracias!

PostgreSQL 9.4.5, compiled by Visual C++ build 1800, 64-bit
Microsoft Windows [Version 10.0.10240] 64-bit





-- 
Ing. Ovidio Jiménez
Cel.: 809-390-4299

Re: Insertar datos en tabla remota

[Daymel Bonne]

Hola Alberto:

No, los datos no se duplican. Fdw lo que hace es que los inserta en la
tabla remota. Lo que te permite FWD es ver los datos como si fueran
locales, pero al seleccionar sobre la tabla, automáticamente se hace el
select remoto. Lo mismo ocurre con los inserts.

Saludos

El 30 ene. 2018 7:46 a.m., "Alberto Cardenas Cardenas" <
alberto.cardenas.c...@gmail.com> escribió:

> Estimdos Tengo una duda con FDW, al crear la tabla tanto en el servidor
> local como en el remoto, donde realmente queda almacenada la data, en ambos
> servidores. Me explico, para poder almacenar el resultado de una query en
> un servidor remoto, he creado una tabla foranea en la BD local, y es donde
> inserto el resultado de la query , esta data se replica vid FDW al servidor
> remoto, entonces tenemos lo siguiente:
>
> La tabla foreanea (local) tiene los datos almacenados
> La tabla remota tiene los datos tambien
>
> osea, los datos se duplican???
>
> Saludos cordiales
>
> El 29 de enero de 2018, 17:05, Martín Marqués 
> escribió:
>
>> Buenas,
>>
>> El día 29 de enero de 2018, 16:15, Alberto Cardenas Cardenas
>>  escribió:
>> > Hola Hellmuth, no me sirve eso porque lo que necesito insertar es el
>> > resultado de unas querys en la tabla remota, no los mismos datos de la
>> tabla
>> > origen, lo que debo insertar son datos procesados obtenidos desde una
>> > funcion local
>>
>> Sirve igual FDW.
>>
>>
>> --
>> Martín Marqués
>> select 'martin.marques' || '@' || 'gmail.com'
>> DBA, Programador, Administrador
>>
>
>

Re: Duda con Barman

[Daymel Bonne]

se supone
> que los incrementales son solo la diferencia del full, o estoy equivocado
>

Por la opción reuse_backup = link, barman reutiliza los ficheros del
respaldo respaldo anterior para hacer los incrementales, y utiliza la
funcionalidad de enlaces duros en linux [1].

El concepto principal es que una copia de seguridad base POSTERIOR
compartirá los archivos que no han cambiados desde la copia de seguridad
ANTERIOR (mediante enlaces duros) [2]. Si te fijas en la salida del
comando, Incremental size : 135.1 KiB (-99.99%), sólo 135.KiB  ha sido
la diferencia con respecto al último. Por lo tanto, no tienes muchas copias
de respaldos de 2.2 GB, sino que, sólo ha sido generado 135 KiB y los
ficheros que no han sido modificados se reutilizan.

[1]
https://askubuntu.com/questions/108771/what-is-the-difference-between-a-hard-link-and-a-symbolic-link
[2] http://docs.pgbarman.org/release/2.3/#incremental-backup

Saludos


>
> Saludos cordiales
>
> El 6 de febrero de 2018, 6:49, Martin Marques <martin.marques@2ndquadrant.
> com> escribió:
>
>> El 05/02/18 a las 22:22, Alberto Cardenas Cardenas escribió:
>> > Hola lista, tengo una duda he leído la documentación de Barman, pero sin
>> > embargo no se como poder restaurar archivos respaldados anteriores a
>> > cierta ventana de tiempo (retention_policy), me explico.
>>
>> Todo lo que sacas del servidor de barman (lo que esta fuera de la
>> ventana que configuraste para retener respaldos) barman no tiene forma
>> de de saber donde está o como usar dichos archivos. Para barman esos
>> archivos ya no están (aunque si están en otro lugar).
>>
>> Queda en vos copiar el backup completo y todos los WALs y escribir el
>> recovery.conf para restaurar el respaldo.
>>
>> > Por ejemplo el parametro así:
>> >
>> > retention_policy = RECOVERY WINDOW OF 7 DAYS
>> >
>> > Y el dia 8 lo muevo a un NAS, , como puedo hacer un recovery de
>> > cualquiera de los dias anteriores a mi política de retención si no están
>> > en Barman, sino en un NAS. Es decir, que pasa si quiero recuperar un
>> > respaldo muy grande de hace 6 meses. Como puedo configurar barman para
>> > que pueda hacer esto sin necesidad de tener esto
>>
>> Como movés los respaldos fuera de la ventana configurada para la
>> retensión al NAS en lugar de borrarlos?
>>
>> > retention_policy = RECOVERY WINDOW OF 7 MONTHS
>> >
>> > Ojalá me haya explicado bien
>>
>> Para mi estaba claro con el primer párrafo. :)
>>
>>
>> --
>> Martín Marquéshttp://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Training & Services
>>
>
>


-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: Ayuda sobre pgadmin4 web

[Daymel Bonne]

Hola Marcos:

WSGIScriptAlias  lo tienes configurado como /pgadmin4, por lo que la URL
debería ser http(s)://direccion.dominio/pgadmin4.

No nos es suficiente con sólo saber que no te funciona, deberías compartir
los errores que aparecen en los logs que deben estar en
/var/log/pgadmin4/pgadmin4.log

Si quieres que pgadmin4 se publique con dirección /, cambia la
configuración del  WSGIScriptAlias a:

WSGIScriptAlias /
/usr/lib/python2.7/site-packages/pgadmin4-web/pgAdmin4.wsgi

Saludos

El 20 de febrero de 2018, 11:59, Marcos Michel Martinez Perez<
mmartin...@uci.cu> escribió:

> Saludos lista, recien estoy incursionando en la instalacion de
> pgadmin4-web sobre centos y configurando el httpd para el acceso mediante
> DNS aqui envio la configuracion de mi virtualhost, pero cuando intento
> levantar la direccion se me abre la pagina principal del httpd llamada
> testing 123.. pero no logro hacer que me levante el pgadmin4. Aqui dejo la
> configuracion de mi virtualhost
>
> 
> ServerName direccion.dominio
> ServerAlias direccion.dominio
>
> LoadModule wsgi_module modules/mod_wsgi.so
> WSGIDaemonProcess pgadmin processes=1 threads=25
> WSGIScriptAlias /pgadmin4 /usr/lib/python2.7/site-packag
> es/pgadmin4-web/pgAdmin4.wsgi
>
> 
> WSGIProcessGroup pgadmin
> WSGIApplicationGroup %{GLOBAL}
> Require all granted
> 
>
> 
>
> La @universidad_uci es Fidel: 15 años conectados al futuro... conectados a
> la Revolución
> 2002-2017
>
>


-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: Acerca de módulo contrib a instalar en Postgres

[Daymel Bonne]

Hola Yessica:

El 2 de agosto de 2018, 18:09, Yessica Brinkmann escribió:

> Buenas,
> Tengo ahora el siguiente problema:
> Al ejecutar en la consola psql para escribir los comandos sql, me responde
> la versión 9.6.1, la cual yo ya había desinstalado, e incluso había escrito
> el comando purge para esa versión. De esta manera, cuando intento hacer
> load de la librería del Index Adviser me aparece un error que dice que la
> librería tiene una versión incompatible, que es de la versión 8.3.23.
> Alguna idea que tengan para resolver el problema?
>

Normalmente en Debian los binarios de postgres se encuentran
en /usr/lib/postgresql//bin. Si quieres usar el psql de la versión
8.4 podrías ejecutarlo directamente mediante.

$ /usr/lib/postgresql/8.4/bin/psql

Si has compilado postgres, deberás buscar la localización de los binarios,
porque depende de las opciones de compilación que usaste.

Es muy probable que no hayas desinstalado todos los paquetes de postgres
9.6. Si quieres saber a que paquete pertenece el comando psql que estás
usando, ejecuta lo siguiente:

dpkg -S /usr/bin/psql

Saludos

Re: django-postgres

[Daymel Bonne]

Hola Marcelo:

El 6 de agosto de 2018, 22:24, Marcelo Giorno
escribió:

> Soy nuevo en el mundo de la programacion
>
> y Necesito que me orienten un poco
>
> Tengo instalado
>  Python 3.4
> PgAdmin4
> Django 1.11.9 instalado con pip
> Posgresql
>
> Estoy trabajando en un entono virtual
>
> Modifique el settings.py de mi app LecturaLog para poder usar Postgress en
> vez de sqlite3
>  pero no logro poder lanzar el servidor de desarrollo de Django.
>

Si no puedes levantar el servidor de desarrollo de django, creo que no es
esta la lista correcta para preguntar. Si es algo acerca de postgres, debes
poner al menos el error asociado para poder ayudar.

Saludos


>
> Estoy muy trabado con psycopg2 ..me pueden orientar un poco
> .....quizas estoy un poco desordenado
>
> Gracias
>
>


-- 
Daymel Bonne   https://www.2ndQuadrant.com/
<https://www.2ndquadrant.com/>
Database Consultant, Training & Services

Re: Replicacion logica con postgres 10.5

[Daymel Bonne]

Hola Gustavo:

El 18 de octubre de 2018, 17:09, Gustavo Vaccaro<
gustavojosevacc...@gmail.com> escribió:

> Hola a todos,
>
> me puse a probar como funciona la replicación lógica con postgres 10.5 y
> me surgió la siguiente pregunta:
> cuando se produce un conflicto porque la clave esta duplicada ¿que es lo
> que hay que hacer?
> ¿se puede saltear el conflicto con pg_replication_origin_advance(node_name
> text, lsn pg_lsn)?
> Probé poniendo el valor remote_lsn que me entrega
> pg_replication_origin_status, pero el conflicto sigue. ¿que valor debo usar?
>
Dos formas de solucionar esto:

1. Borrar la fila del conflicto.
2. utilizar pg_replication_origin_advance

https://www.postgresql.org/docs/10/static/logical-replication-conflicts.html

Saludos

Re: Dificil situacion con Lokcs...

[Daymel Bonne]

Hola:

El sáb., 5 de ene. de 2019 a la(s) 17:43, Carlos T. Groero Carmona (
cton...@gmail.com) escribió:

> Alvaro escribio:
>>
>
> Como tienes lock_timeout, tu problema seguramente no fue de locks sino
>> de lentitud.
>>
>
> Por lo que me surge la duda, todo parece indicar que la transaction se
> inicia con el update pero por algun problema de lentitud se queda esperando
> una respuesta, durante ese tiempo la tabla o la tupla esta lock...
>
> Mi lock_timeout es de 10 segundos, por lo tanto despues de 10 segundo esa
> transacion, sera eliminada?
>
> Si se elimina entonces no se recibe ni el commit ni el rollback, por lo
> tanto cualquier otra transaction que se vaya a ejecutar en esa tabla sera
> detenida esperando que la transaction anterior se complete ya se por un
> commit o un rollbacks...
>

No toda transacción sobre la tabla será bloqueada. Sólo las que necesiten
del registro que se está actualizando. En tu caso, los updates sobre el
mismo registro serán encolados.

Saludos

-- 
Daymel Bonne
Database Consultant, Training & Services
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/ <https://www.2ndquadrant.com/>

Re: REPLICACION PERO SOLO DE UN CAMPO NO DE UNA TABLA COMPLETE(REGISTRO)

[Daymel Bonne]

Buenas tardes Heriberto:

El vie., 18 de ene. de 2019 a la(s) 13:31, heriberto giron (
heribertogir...@gmail.com) escribió:

> Buenas tardes
>
>
> alguien me puede indicar, como se puede hacer?, si es posible. replicar
> información con postgres 10.5 pero no de todo el registro (todos los
> campos) sino solo de un campo
>

No es posible con la implementación de la replicación lógica nativa en
pg10.
Puedes lograr lo que quieres utilizando pglogical (
https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/) que
brinda filtrado de columnas y/o registros.

Saludos

Re: POSTGRES DEJA DE FUNCIONA

[Daymel Bonne]

Hola:

El mar., 8 de ene. de 2019 a la(s) 08:31, FLOR AVILA ELIAS (
fav...@ditelgroup.com) escribió:

> Estimados Señores,
>
> Hace unos dias tengo un problema que hace que el postgres deje de
> funciona, cabe indicar que trabaja en un servidor Centos 6, con postgres
> 9-3 y pgbouncer, agradeceria si me pueden dar indicaciones de que
> informacion necesitan para poder brindarles.
> Yo adjunto informacion:
> - cpuinfo
> - meminfo
> - postgresql.conf
> - pg_hba.conf
> - pgbouncer.ini
>
> Cabe indicar que estuvo funcionando correctamente, hasta que el viernes
> quitaron unas redes publicias, porque antes teniamos 3 y ahora solo hay una.
>
> Desde ahi a ciertas horas se cae el postgres pero el apache sigue
> funcionando.
>
>
Hay cosas bastante raras con los datos que envías.

Según el fichero meminfo20.txt ese servidor tiene de RAM 3906016KB (3.9 GB
aprox), sin embargo el postgresql.conf en shared_buffers tiene 6400MB (6GB
aprox), ummm bastante raro no crees? Más sospechoso aún es que
effective_cache_size tenga el valor de 4228MB, valor menor que
shared_buffers. Todo un despropósito esta configuración.

Si postgres se dejó de funcionar de repente, debió generar un fichero .core
en el directorio de datos. Con ayuda especializada se puede investigar la
causa del fallo.

Sabías que la versión 9.3 está descontinuada desde el año pasado? Creo que
te quedan pocas opciones para buscar ayuda seria si no actualizas.

Suerte. Saludos

Re: MOVER DIRECTORIO DE POSTGRES-9.3 EN CENTOS 6

[Daymel Bonne]

Hola

El mar., 8 de ene. de 2019 a la(s) 07:06, Stephen Amell (
mrstephenam...@gmail.com) escribió:

> Hola:
>
> Otra alternativa, bastante simple, es apagar el motor, mover la carpeta
> data, encender el motor con el -D a la nueva ruta (si vas por servicio, hay
> que tocar el /etc/init.d/postgresql-9.3, la ruta PGDATA y PGLOG)
>

Simplemente te recomiendo hacer un enlace del nuevo directorio de datos a
la localización por defecto del directorio de datos de postgres.
Asumiendo que el directorio de datos por defecto se crea en
/var/lib/pgsql/9.3/data deberás hacer esto:

ln -s /home/pgdata /var/lib/pgsql/9.3/data

Deberás asegurarte además que /home/pgdata tenga los permisos correctos
(700).

Con esto evitas tener que modificar el fichero del servicio de postgres.

Saludos

Re: Funciones y Plan Caching

[Daymel Bonne]

Hola Stephen:

El vie., 8 de feb. de 2019 a la(s) 13:34, Stephen Amell (
mrstephenam...@gmail.com) escribió:

> Hola Lista,
>
> Les escribo para preguntarles si alguien noto esto a la hora de tener mal
> rendimiento en funciones:
> 41.10.2. Plan Caching
>
> The PL/pgSQL interpreter parses the function's source text and produces
> an internal binary instruction tree the first time the function is called
> (within each session). The instruction tree fully translates the PL/pgSQL 
> statement
> structure, but individual SQL expressions and SQL commands used in the
> function are not translated immediately.
>
> As each expression and SQL command is first executed in the function, the
> PL/pgSQL interpreter parses and analyzes the command to create a prepared
> statement, using the SPI manager's SPI_prepare function. Subsequent
> visits to that expression or command reuse the prepared statement. Thus, a
> function with conditional code paths that are seldom visited will never
> incur the overhead of analyzing those commands that are never executed
> within the current session. A disadvantage is that errors in a specific
> expression or command cannot be detected until that part of the function is
> reached in execution. (Trivial syntax errors will be detected during the
> initial parsing pass, but anything deeper will not be detected until
> execution.)
>
> PL/pgSQL (or more precisely, the SPI manager) can furthermore attempt to
> cache the execution plan associated with any particular prepared statement.
> If a cached plan is not used, then a fresh execution plan is generated on
> each visit to the statement, and the current parameter values (that is,
> PL/pgSQL variable values) can be used to optimize the selected plan. If
> the statement has no parameters, or is executed many times, the SPI manager
> will consider creating a *generic* plan that is not dependent on specific
> parameter values, and caching that for re-use. T*ypically this will
> happen only if the execution plan is not very sensitive to the values of
> the PL/pgSQL variables referenced in it. If it is, generating a plan each
> time is a net win. See PREPARE
> <https://www.postgresql.org/docs/9.6/sql-prepare.html> for more information
> about the behavior of prepared statements.*
>
> *Because PL/pgSQL saves prepared statements and sometimes execution plans
> in this way, SQL commands that appear directly in a PL/pgSQL function must
> refer to the same tables and columns on every execution; that is, you
> cannot use a parameter as the name of a table or column in an SQL command.
> To get around this restriction, you can construct dynamic commands using
> the PL/pgSQL EXECUTE statement — at the price of performing new parse
> analysis and constructing a new execution plan on every execution.*
>
> The mutable nature of record variables presents another problem in this
> connection. When fields of a record variable are used in expressions or
> statements, the data types of the fields must not change from one call of
> the function to the next, since each expression will be analyzed using the
> data type that is present when the expression is first reached. EXECUTE can
> be used to get around this problem when necessary.
>
> https://www.postgresql.org/docs/9.6/plpgsql-implementation.html
>
> Mas alla del execute que menciona, se sabe de alguna alternativa, ¿quizás
> los nuevos stored procedures?
>

¿Alternativa a que? Está claro cómo es que funciona la caché del plan de
ejecución en la documentación. Tienes algún problema en específico?

Saludos


-- 
Daymel Bonne
Database Consultant, Training & Services
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/ <https://www.2ndquadrant.com/>

Re: Dudas varias pglogical

[Daymel Bonne]

Hola:

El lun., 27 de may. de 2019 a la(s) 09:56, max araya (mxar...@gmail.com)
escribió:

> En realidad no he tenido ningun problema, todo lo contrario me esta
> funcionando perfecto, solo es una duda de si por alguna razon pglogical
> podria hacer que la bd provider (BD productiva) me causa algun fallo.
>

No, siempre que tengas actualizado postgres y pglogical.


>
> Lo unico extraño que me ha pasado es que no me dejara borrar una tabla del
> provider que no estaba replicando con pglogical, lo resolvi dandole full
> permisos al usuario de pglogical sobre esa tabla.
>
> Sobre el monitoreo es mas que todo para verificar que la replicacion se
> este haciendo bien o simplemente si se da algun error que me avise y poder
> revisarlo.
>

En caso de error siempre vas poder buscar en los logs tanto del proveedor
como en el suscriptor registros que hacen referencia a pglogical. Del
monitoreo, siempre que avance la replicación no debes tener problemas.
Tenés que estar monitoreando la información de la vista pg_stat_replication
y pg_replication_slots.

Saludos

Re: Dudas varias pglogical

[Daymel Bonne]

El lun., 27 de may. de 2019 a la(s) 09:28, max araya (mxar...@gmail.com)
escribió:

> Buenas tardes,
>
> Tengo unas cuantas dudas sobre pglogical:
>
>1. Hay alguna posibilidad de que pglogical provoque que la BD provider
>falle?
>
>
Algún dado que te sugiere que pglogical fue el causante de la falla?


>
>1. Existe alguna herramienta o forma de monitorear mas profundamente
>si pglogical esta trabajando correctamente aparte de usar queries en
>provider y subscriber?
>
>
Esto es ambiguo. Alguna información en específico que quieras tener en el
monitoreo? A que te refieres con "más profundamente"?

Saludos

Re: Fallo en función

[Daymel Bonne]

Hola José:

El vie., 31 de may. de 2019 a la(s) 06:10, José Vicente Zahonero García (
joviz...@hotmail.com) escribió:

> Hola, tengo esta función:
> CREATE OR REPLACE FUNCTION inserciones(trayecto varchar, tempo varchar,
> espacio numeric)
>  returns void AS $$
>
> declare
>
>  spaces integer;
>  hora integer;
>  minuto integer;
>  segundo integer;
>  resultado real;
>  tiempo_en_minutos real;
>  calorias real;
>
>
> begin
>
> spaces := espacio*1000;
> hora := cast(substring(tempo from 1 for 2));
> minuto := cast(substring(tempo from 4 for 2));
> segundo := cast(substring(tempo from 7 for 2));
> hora := hora*3600;
> minuto := minuto*60;
> resultado := ((spaces/(hora+minuto+segundo))*3.6);
> tiempo_en_minutos := ((hora+minuto+segundo)/60);
> calorias := (70*0.21)*tiempo_en_minutos;
>
> insert into datos (recorrido,tiempo,distancia,calorias,kmh,fecha)
> values (trayecto,tempo,spaces,calorias,resultado,current_date);
>
> end;
> $$ language 'plpgsql';
> Al ejecutarla me da el error:
> Unterminated dollar quote started at position 0 in SQL $$ language
> 'plpgsql';. Expected terminating $$
>

CREATE OR REPLACE FUNCTION public.inserciones(trayecto character varying,
tempo character varying, espacio numeric)
 RETURNS void
 LANGUAGE plpgsql
AS $function$
declare
 spaces integer;
 hora integer;
 minuto integer;
 segundo integer;
 resultado real;
 tiempo_en_minutos real;
 calorias real;
begin
spaces := espacio*1000;
hora := cast(substring(tempo from 1 for 2) as integer);
minuto := cast(substring(tempo from 4 for 2) as integer);
segundo := cast(substring(tempo from 7 for 2) as integer);
hora := hora*3600;
minuto := minuto*60;
resultado := ((spaces/(hora+minuto+segundo))*3.6);
tiempo_en_minutos := ((hora+minuto+segundo)/60);
calorias := (70*0.21)*tiempo_en_minutos;

insert into datos (recorrido,tiempo,distancia,calorias,kmh,fecha)
values (trayecto,tempo,spaces,calorias,resultado,current_date);
end

$function$;

Saludos

Re: Formas de Replicar

[Daymel Bonne]

Buenos días:

El mié., 12 de jun. de 2019 a la(s) 04:41, kernel (jucab...@gmail.com)
escribió:

> Hola,
>
> Estoy viendo que hay diferentes formas de replicacion, yo hasta ahora
> utilizaba un metodo de Hot Standby y Streaming replication.
>
> cuando empece utilice esta guia :
>
> https://e-mc2.net/es/hot-standby-y-streaming-replication?page=1
>
> El otro dia buscando informacion de pg_basebackup me encontre con esta
> otra guia :
>
> https://www.unixmen.com/setup-postgresql-replication-centos/
>

La verdad es que estás viendo guias bien antiguas.


> Ve o que esta ultima es mas facil de configurar, pero estoy probando y
> observo que si paro el servidor de replica e intento , por ejemplo crear
> una base de  datos en  servidor principal, se queda esperando y hasta que
> no levanto el servidor de  respaldo no continua.
>
>
>
Esto pasa porque en el segundo, se configura una replicación sincrónica,
fíjate en el parámetro synchronous_standby_names.


> Con el metodo que yo utilizo   (Hot Standby y Streaming replication) ,
> puedo tener parada la maquina de replica varios dias (dependiendo del
> wal_keep_segment) sin ningun problema y cuando levanto la replica se pone
> en linea y punto.
>
>
>
Deberías ver los [replication_slots](
https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION-SLOTS
)


> Las verdad es que tengo un poco de lio, creo que la segunda forma es mas
> sencilla de configurar ,( no hay que pasar claves ssh, menos scripts), pero
> veo que no permite la perdida de conexion con el replica.
>
> Para liarme mas, esto pensado en poder utilizar balanceo, estoy viendo
> pgpool, veo que tambien puede encargarse de la replicacion, no se por donde
> seguir
>
> ¿que es mejor para mi?, ¿alguna guia clarificadora?, ¿en Castellano?
>

Con un poco de esfuerzo, Google Translate y la [documentación de postgres](
https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION)
te darán el 99% de lo que tienes que saber para implementar correctamente
la replicación.

Saludos


-- 
Daymel Bonne
Database Consultant, Training & Services
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/ <https://www.2ndquadrant.com/>

Re: [MASSMAIL]Ayuda Técnica

[Daymel Bonne]

Buenas:

El mar., 11 de jun. de 2019 a la(s) 15:51, Departamento Soporte Técnico (
mateosat...@hotmail.com) escribió:

> ya esta agregado esa configuracion: al hacer un netsat -netstat:
>
> tcp0  0 0.0.0.0:1   0.0.0.0:*
> LISTEN  65529/perl
> tcp0  0 127.0.0.53:53   0.0.0.0:*
> LISTEN  342/systemd-resolve
> tcp0  0 0.0.0.0:22  0.0.0.0:*
> LISTEN  22169/sshd
> tcp0  0 127.0.0.1:3306  0.0.0.0:*
> LISTEN  47344/mysqld
> tcp6   0  0 :::80   :::*LISTEN
>  24977/apache2
> tcp6   0  0 :::1:::*LISTEN
>  65529/perl
> tcp6   0  0 :::8080 :::*LISTEN
>  1048/java
> tcp6   0  0 :::21   :::*LISTEN
>  22567/vsftpd
> tcp6   0  0 :::22   :::*LISTEN
>  22169/sshd
> tcp6   0  0 ::1:3350:::*LISTEN
>  16847/xrdp-sesman
> tcp6   0  0 :::3389 :::*LISTEN
>  16857/xrdp
> tcp6   0  0 127.0.0.1:8005  :::*
>  LISTEN  1048/java
> --
> agrege a los Iptables:
> iptables -A INPUT -i eth0 -p tcp --destination-port 5432 -j ACCEPT
> iptables-save -c
> 
> Pero no refleja...
>

Yo comenzaría primero viendo si el servicio de postgres está en ejecución.
Por la salida del comando netstat, no hay registro de que postgres está
escuchando por interfaz/puerto alguno, lo que es muy raro. Sospecho que no
está corriendo el servicio.

Saludos

Re: problema al intentar recuperar PITR

[Daymel Bonne]

Buenas:

El mar., 9 de jul. de 2019 a la(s) 11:02, Alvaro Herrera (
alvhe...@2ndquadrant.com) escribió:

> Guillermo E. Villanueva escribió:
> > Gracias por tu respuesta Alvaro,
> > recovery.con tiene:
> > restore_command = '/usr/local/pgsql/BK20190705/%f %p'
>

No te falta el cp? o sea debería ser:

restore_command = 'cp /usr/local/pgsql/BK20190705/%f %p'

Saludos

Re: Replicación + upgrade

[Daymel Bonne]

Hola, buen día:

El mié., 14 de ago. de 2019 a la(s) 07:50, Stephen Amell (
mrstephenam...@gmail.com) escribió:

> Hola,
>
> Yo creo que vas a tener que empezar de cero. Base y demás.
>
> Por las dudas, espera otra opinion.
>

No tienes que empezar de cero necesariamente. La documentación detalla los
pasos a seguir para hacer un upgrade los servidores Standby.

Puedes ver los pasos aquí:
https://www.postgresql.org/docs/11/pgupgrade.html#PGUPGRADE-STEP-REPLICAS

Re: Exportaciòn de tablas a CSV

[Daymel Bonne]

Buenas tardes:

El jue., 2 de abr. de 2020 a la(s) 12:56, Rafael Valenzuela (
rav...@gmail.com) escribió:

> Buenas :
> Tengo una duda a ver si alguien con mas experiencia que yo me pueda
> arrogar algo de luz. Estoy exportando unas tablas a formato CSV pero al
> ejecutar el copy (*COPY (SELECT * FROM  table) TO STDOUT WITH CSV HEADER;*)
> me saca estos errores.
>
>- ERROR:  canceling statement due to conflict with recovery
>- DETAIL:  User query might have needed to see row versions that must
>be removed.
>
> He aumentado el parametro *statement_timeout* a 100 pero aun así me
> falla y lo que mas me sorprende es que el tamaño más grande es de 12 GB
> pero el listado seria este.
>
>- '475 MB'
>- '475 MB'
>- '12 GB'
>- '34 MB'
>- '83 MB'
>- '1312 kB'
>- '128 kB'
>- '68 MB'
>- '63 MB'
>
> Tengo buena conectividad  entre el host de la base de datos, no se si es
> posible cambiar alguna settings mas ... la versión  que tengo es
>
>  PostgreSQL 9.6.16 on x86_64-pc-linux-gnu, compiled by clang version
> 7.0.0-3~ubuntu0.18.04.1 (tags/RELEASE_700/final), 64-bit
>

Esto se produce porque la consulta que estás realizando en ese servidor
Standby accede a datos que han sido actualizados
o eliminados en el servidor Primario, y la consulta es cancelada porque los
datos ya no son válidos.

Deberás en el servidor Standby establecer el parámetro hot_standby_feedback
= on.

ALTER SYSTEM SET hot_standby_feedback = on;

Saludos

-- 
Daymel Bonne
Database Consultant, Training & Services
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/ <https://www.2ndquadrant.com/>

Re: Implementar Alta Disponibilidad

[Daymel Bonne]

El jue., 14 de may. de 2020 a la(s) 15:42, Ing.Daniel Bojorge (
debs.fo...@gmail.com) escribió:

> Hola a todos.  ¿Tendrá alguno una guía o tutorial (inglés o español) donde
> se monta alta Disponibilidad para PostgreSQL Server?
>
> Soy algo nuevo en ese tema y requiero montar eso.  ¿Podrían ayudarme?
>
> Gracias y disculpen las molestias
>

Te sugiero que veas https://repmgr.org/

Saludos

Re: alternativa pg_xlog_replay_pause

[Daymel Bonne]

El mié., 22 de jul. de 2020 a la(s) 11:38, kernel (jucab...@gmail.com)
escribió:

>
> Hola tengo una script para hacer una backup de una maquina esclava :
>
> file=$(date +%a-%H-%M)
> PGCLIENTENCODING=UTF-8
> export PGCLIENTENCODING
> psql  -U postgres -c 'SELECT pg_xlog_replay_pause()' -o /u/temp/x
> /usr/bin/pg_dump -U postgres $2  -f $1/datos.sql
> psql  -U postgres -c 'SELECT pg_xlog_replay_resume()' -o /u/temp/x
> tar -P -zcf $1/$file.gz $1/datos.sql >/dev/null 2>&1
> rm $1/datos.sql
>
>
> He instalado postgresql version 11 y ahora me dice que no existe la funcion
>
>
> ERROR:  function pg_xlog_replay_pause() does not exist
> LÍNEA 1: SELECT pg_xlog_replay_pause()
>
>
> ¿hay alguna funcion que la sustituya?
>

Aquí puedes mirar:

https://www.postgresql.org/docs/11/functions-admin.html#FUNCTIONS-RECOVERY-CONTROL-TABLE


-- 
Daymel Bonne
Database Consultant, Training & Services
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/ <https://www.2ndquadrant.com/>

Re: The pg_checksums utility con replicas

[Daymel Bonne]

El mié., 22 de jul. de 2020 a la(s) 08:13, Hellmuth Vargas (hiv...@gmail.com)
escribió:

> Hola Lista
>
> Tenemos una instalación en PostgreSQL 9.5 compuesta de 1 mater y 3
> replicas, estamos en revisión  de tareas y procedimientos para  su
> actualización a PostgreSQL 12, entre las  nuevas funcionalidades, es
> posible  habilitar checksum en un servidor apagado sin necesidad de recrear
> el cluster completamente por medio de pg_checksums según describe esta
> página:
>
>
> https://www.cybertec-postgresql.com/en/discovering-less-known-postgresql-12-features/
>
>
> La pregunta es: y en mi caso, para habilitar  pg_checksums tanto en la
> master  con en las 3 replicas sin tener que recrear las réplicas (una vez
> actualizadas a PostgreSQL 12), esto es posible?
>

Si es posible. Puede seguir el siguiente procedimiento:

Escenario: Tanto el Primario como los Standbys tienen sumas de verificación
de datos deshabilitadas, y el objetivo es habilitar las sumas de
verificación de datos.

* Primero, detenga limpiamente los Standbys y active sumas de verificación
con *pg_chechsum --enable*.
* Inicie los Standbys y espere que se pongan al día con el Primario.
* Detenga limpiamente el primario.
* Promueva uno de los Standbys y realice un failover hacia él - En este
punto los demás Standby recibirán los cambios del recién promovido -
* Habilitar sumas de comprobación en el Primario anterior.
* Vuelva a conectarlo al Standby promovido, todas instancias ahora tienen
sumas de verificación habilitadas.

Saludos

-- 
Daymel Bonne
Database Consultant, Training & Services
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/ <https://www.2ndquadrant.com/>

Re: upgrade 9.2 a 13

[Daymel Bonne Solís]

Buenas tardes:

El mar, 12 de oct. de 2021 a la(s) 12:00, Guillermo E. Villanueva (
guillermo...@gmail.com) escribió:

> Buenas! ¿Es posible utilizar la herramienta pg_upgrade en un solo paso
> para pasar de un opensuse 12 con postgresql 9.2 a un centos 8 con
> postgresql 13? cada uno en VM diferentes dentro de la misma red local.
>
> Desde ya muchas gracias!
>

 No, pg_upgrade es para la actualización de versión mayor en el mismo
servidor.

Saludos

Re: Barman con almacenamiento redundante

[Daymel Bonne Solís]

El mar, 28 de sep. de 2021 a la(s) 08:55, Guillermo E. Villanueva (
guillermo...@gmail.com) escribió:

> Buen día. Se que es posible con barman cli, almacenar los wal directamente
> en un cloud.
> Pero si yo quiero guardarlos en mi barman on-premise y de ahi tener una
> copia en cloud junto con los correspondientes full backup es posible?
> Ante un fallo del barman on-premise, es posible rearmarlo recuperando los
> archivos del cloud?
>
> Desde ya muchas gracias por sus comentarios.
>

Efectivamente puedes hacer lo que pides. El procedimiento sería configurar
en el Barman on Premise un hook para que una vez terminado el
respaldo, lo suba al S3. Y además si quieres archivar los WALs también en
S3, existe un hook que se ejecuta cada vez que archiva un WAL.

La sección de la documentación es:

https://docs.pgbarman.org/release/2.13/#barman-client-utilities-for-the-cloud-barman-cli-cloud

Saludos

Re: Optimización de consulta

[Daymel Bonne Solís]

El mar, 7 jun 2022 a la(s) 12:21, Guillermo E. Villanueva (
guillermo...@gmail.com) escribió:

> Buenas tardes cómo andan? quizá me puedan dar una mano, estoy tratando de
> optimizar una consulta con varios joins, agrupamientos y unos cuantos
> filtros, según lo que puedo ver en el explain  las expresiones:
>
> *product_.status = 1 and and product_.qty > 0*
>
> provocan seq. scan y el mayor costo y tiempo de mi consulta
> la tabla product_ tiene 69300 filas
> status = 1 son 49500
> qty > 0 son 65700
>
> el explain me dice:
> ->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
> width=30) (actual time=0.032..39.454 rows=15674 loops=3)
> Filter: ((qty > '0'::numeric) AND (status = 1))
>  Rows Removed by Filter: 7454
>
> Si creo índices individuales o combinando ambas columnas no mejora, sigue
> haciendo seq. scan
>
> Creen que hay alguna forma de mejorarlo? o ya estoy en la mejor versión de
> la query?
>
> Desde ya muchas gracias por las ideas.
>

La explicación del comportamiento viene dado por los datos que nos muestras:

Total de registros: 69300
Tuplas que cumplen con `status = 1` son 49500 representa el 71%
Tuplas que cumplen con `qty > 0` son 49500 que son 84%

Postgres no utilizará índices, es ménos costoso hacer un scan secuencial
sobre la tabla que primero buscar en los índices y luego ir a la tabla para
obtener los registros.

Saludos

Re: retención de arhivos wal

[Daymel Bonne Solís]

Hola Guillermo:

> El 18 may. 2023, a las 10:01, Guillermo E. Villanueva 
>  escribió:
> 
> Buen día, tengo un servidor postgres 11.5 en debian, replicando por 
> streaming, aparte tiene respaldo en un barman a través de archive_command con 
> rsync.
> La replicación funciona bien. Si reviso los wal en el servidor standby, estan 
> bien y se rotan bien.
> El respaldo de los archivos wal funciona bien.
> 
> El probelma es que no se están borrando los archivos wal del master.
> En la configuración tengo:
> wal_level = hot_standby
> synchronous_commit = local
> checkpoint_timeout = 15min
> max_wal_senders = 1
> wal_keep_segments = 100
> max_replication_slots = 3
> synchronous_standby_names = 'standby'
> hot_standby = on
> archive_mode = on
> archive_command = 'rsync -a %p 
> 
> Me pueden tirar algunas pistas para descubrir porque no se borran los logs?


Puedes revisar si:

1. Hay un slot creado que no está siendo utilizado
2. El archive_command arroja un error al ejecutarse. Puedes ver la vista 
pg_archiver_stat y el log de postgres

Si usas barman, te aconsejo utilizar la utilidad barman-wal-archive para el 
archivado en el archive_command 
https://docs.pgbarman.org/release/3.5.0/barman-wal-archive.1.html

Saludos



signature.asc
Description: Message signed with OpenPGP

Re: retención de arhivos wal

[Daymel Bonne Solís]

> El 18 may. 2023, a las 11:30, Guillermo E. Villanueva 
>  escribió:
> 
> Muchas gracias por la respuesta, respondo en tu mensaje
> 
> El jue, 18 may 2023 a las 12:27, Diego Feito ( >) escribió:
>> archive_command esta retornando true, no?
> Si, de hecho tengo todos los wal copiados en el barman correctamente
> 
>> el slot esta sincronizaado?
> Es un servidor que nos lo entregaron configurado
> Utilizo streaming replication, no deberían haber slots o si?
> si hago  select * from pg_replication_slots;
> el resultado es
>   slot_name  | plugin | slot_type | datoid | database | temporary | active | 
> active_pid |   xmin   | catalog_xmin | restart_lsn  | confirmed_flush_lsn
> -++---++--+---+++--+--+--+-
>  iolrep_slot || physical  ||  | f | f  |  
>   | 16083087 |  | 3F2/9A1C |
> 
> No debería tener nada no? Será esto lo que está provocando que no se reciclen 
> los wal?

Efectivamente tienes un slot que no está siendo utilizado. Elimínalo y debería 
bastar para que comience a liberar WALs el servidor.

Saludos



signature.asc
Description: Message signed with OpenPGP

Re: barman backup started con error

[Daymel Bonne Solís]

Hola Guillermo:

> On 2 Feb 2024, at 06:50, Guillermo E. Villanueva  
> wrote:
> 
> Entorno Debian, Postgres  y Barman 2.18
> Buen día, mi barman 2.18 había iniciado un full backup (programado con 
> crontab los días jueves) y se quedó sin espacio en disco. 
> Cambié el periodo de retención y liberé espacio.
> El problema es que si hago un list-backup me sigue apareciendo el último full 
> (el que se quedó sin espacio) como "STARTED".
> 
> Si hago un 
> ps -aux | grep barman 
> barman   2964567  2.0  0.0  44836 30448 ?Ss   11:38   0:00 
> /usr/bin/python3 /usr/bin/barman -c /etc/barman.conf -q archive-wal eprensa
> barman   2965877  0.0  0.0   2892   984 ?S11:38   0:00 /bin/sh -c 
> barman_command(){ gzip -c > "$2" < "$1";}; barman_command 
> '/home/barman/eprensa/incoming/0001408700C1' 
> '/home/barman/eprensa/wals/00014087/0001408700C1.tmp'
> barman   2965878 43.0  0.0   3516  1824 ?R11:38   0:00 gzip -c
> root 2965879  0.0  0.0  16944 10472 ?Ss   11:38   0:00 sshd: 
> barman [priv]
> 
> Creo que lo que se ve de barman es el archivado de wals no el "barman backup" 
> cierto?
> 
> Puedo cancelar limpiamente el último backup que figura como STARTED ?
> Podrían recomendarme por favor como seguri? 
> 
> Desde ya muchas gracias!!

Si es correcto. Lo que ves es la actividad relacionada al archivado de los WALs.

Lo que debes hacer es eliminar el backup ya que no finalizó y no es 
consistente. Y seguido haz uno nuevamente.

Por comentarte algo respecto a la versión de Barman, estás utilizando una más 
que obsoleta (de Enero de 2021). Proponte actualizar Barman y te ahorrarás 
muchos dolores de cabeza en el futuro.

Saludos



signature.asc
Description: Message signed with OpenPGP

Re: Error en barman

[Daymel Bonne Solís]

Hola Guillermo:

> On 13 Mar 2024, at 09:34, Guillermo E. Villanueva  
> wrote:
> 
> Agrego una pregunta, si yo todavía no puse "barman cron" en crontab de ningun 
> usuario (ni root, ni barman) , ¿por qué se está ejecutando algo que genera el 
> error mencionado?

El paquete de Barman instala un cron en /etc/cron.d/barman donde ejecuta cada 
minuto el comando `barman cron`. 

Saludos





signature.asc
Description: Message signed with OpenPGP

Estabilidad de la API interna

[Daymel Bonne Solís]

Buenas tardes:

Tengo una duda relacionada con la API interna de Postgres.

Que tan posible es que una extensión que utilice llamadas a la API interna de 
Postgres, no funcione en las siguientes versiones menores?

Ej. Una extensión escrita en C compilada para la versión 16.0 seguirá 
funcionando para versiones 16.X superiores?

Saludos

signature.asc
Description: Message signed with OpenPGP

Re: Estabilidad de la API interna

[Daymel Bonne Solís]

Gracias por la pronta respuesta:

> On 4 Apr 2024, at 3:02 PM, Juan  wrote:
> 
> Hola , mientras no cambies de version, andará, hize funciones en C para 
> postgres y
> Mientras no cambie la rama de postgres funcionan si vas para abajo o arriba 
> no funciona,
> esa fue mi experiencia. yo hize una modificacion a contrib y eso tambien 
> agrega dependencias
> saludos
> 
> On Thu, Apr 4, 2024 at 4:47 PM Daymel Bonne Solís  <mailto:daymelbo...@gmail.com>> wrote:
>> Buenas tardes:
>> 
>> Tengo una duda relacionada con la API interna de Postgres.
>> 
>> Que tan posible es que una extensión que utilice llamadas a la API interna 
>> de Postgres, no funcione en las siguientes versiones menores?
>> 
>> Ej. Una extensión escrita en C compilada para la versión 16.0 seguirá 
>> funcionando para versiones 16.X superiores?
>> 
>> Saludos


Esas son buenas noticias. Gracias

Saludos



signature.asc
Description: Message signed with OpenPGP

Re: Migración de servidor postgresql

[Daymel Bonne Solís]

Hola Jairo:

> On 25 Apr 2024, at 7:05 PM, Jairo Graterón  wrote:
> 
> Muchas gracias, el sábado lo pongo a prueba. 
> 
> Saludos.
> 
> El jue, 25 abr 2024 a las 15:25, Guillermo E. Villanueva 
> (mailto:guillermo...@gmail.com>>) escribió:
>> Jairo, si son servidores diferentes, yo tenía requerimiento de downgrade 0, 
>> lo que hice fue instalar pg 16 en el servidor destino, hacer replicación 
>> logica, esperar a que todo esté copiado y sincronizado y listo!!!  Leí y 
>> saqué ideas de: 
>> https://knock.app/blog/zero-downtime-postgres-upgrades#aborting-the-replication-of-one-table
>> 
>> El jue, 25 abr 2024 a las 14:47, Jairo Graterón (> >) escribió:
>>> Saludos lista
>>> 
>>> Cuál es la mejor estrategia para migrar de servidor (ubuntu 18 a 22) y 
>>> versión postgresql (12 a 16) con el menor tiempo de inactividad.
>>> 
>>> La BD ocupa aprox. 2TB
>>> 
>>> 


Es un tema en el que considero que hay poca documentación detallada de los 
pasos a seguir para lograrlo. Sin embargo hay guías muy completas que pueden 
ayudar. Te puedo sugerir una que es la que me parece más completa. La puedes 
encontrar en 
https://gitlab.com/postgres-ai/postgresql-consulting/postgres-howtos/-/blob/main/0077_zero_downtime_major_upgrade.md

Puedes también ver un playbook de ansible muy interesante y bien documentado 
que hicieron los técnicos de Gitlab que muestra el proceso de actualizar a una 
versión mayor utilizando logical replication (con el truco "físico a lógico"). 
La diferencia es que su infraestructura es posiblemente más compleja que lo que 
puedas tener. Pero, si le das un vistazo al Readme.md puedes encontrar varias 
pasos interesantes que ellos que utilizan para verificar que el proceso se 
realiza de forma correcta, así como consideraciones cuando hay que hacer 
rollback en caso de emergencia. Todo esto lo  puedes encontrar en 
https://gitlab.com/gitlab-com/gl-infra/db-migration/-/tree/master/pg-upgrade-logical?ref_type=heads#upgrade-plan

Saludos

Bonus: Por lo general recomiendo 100% el repositorio 
https://gitlab.com/postgres-ai/postgresql-consulting/postgres-howtos.git porque 
contiene muchas recetas sobre muchos aspectos de administración de postgres



signature.asc
Description: Message signed with OpenPGP