Re: Conflicto entre pg_dump y transacción.

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 forma de hacer el dump? Digo tendría
que tirarlo en el maestro o de otra forma (más allá de tu propuesta)?
Actualmente en el maestro estoy haciendo el bkup físico (que no puedo hacer
en el slave por no tener allí activo el archivado del WAL).

Cualquier sugerencia es bienvenida.

Saludos.
Federico.

El 3 de mayo de 2018, 9:59, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
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>
>
> 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.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>