Re: Conflicto entre pg_dump y transacción.

Gracias Martín; es como decís.

El 3 de mayo de 2018, 12:58, Martin Marques <martin(dot)marques(at)2ndquadrant(dot)com>
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 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 stg ERROR: cancelando la sentencia
> >> debido a un conflicto con la recuperación
> >> 2018-05-02 20:13:39 GMT+3 postgres stg DETALLE: La consulta del usuario
> >> pudo haber necesitado examinar versiones de tuplas que debían
> eliminarse.
> >
> > 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
>
> > La idea es que el parámetro hot_standby_feedback se active para la
> > sesión de pg_dump, con lo cual evitas que un VACUUM en el primario
> > elimine tuplas que el pg_dump necesita.
>
> Estaba a punto de recomendar usar los parámetros
> max_standby_streaming_delay y max_standby_archive_delay y recorde que el
> standby es sincronico, por lo que congelaria las transacciones en el
> maestro.
>
> Saludos
>
> --
> Martín Marqués http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>