Gracias Martín; es como decís.
El 3 de mayo de 2018, 12:58, Martin Marques <martin.marq...@2ndquadrant.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 >
