Re: Conflicto entre pg_dump y transacción.

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, 13:13, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
escribió:

> 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 <opciones>
> >
> > Eso no va a funcionar ya que hot_standby_feedback requiere un sighup del
> > postmaster para applicar el cambio.
> >
> > $ PGOPTIONS='-c hot_standby_feedback=1' psql -h localhost
> > psql: FATAL: el parámetro «hot_standby_feedback» no se puede cambiar en
> > este momento
>
> Ajá.
>
> 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 que en 9.1 no hay ALTER SYSTEM, así que le tocaría hacer esa
> parte a mano, editando el archivo de configuración (o mejor teniendo un
> archivo .conf separado que lleva sólo el parámetro hot_standby_feedback,
> el cual es fácil reescribir completo, y al cual el postgresql.conf hace
> "include").
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>