| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Federico Pascual <federico(dot)pascual(at)gmail(dot)com> |
| Cc: | pgsql-es-ayuda(at)postgresql(dot)org |
| Subject: | Re: Conflicto entre pg_dump y transacción. |
| Date: | 2018-05-03 12:59:29 |
| Message-ID: | 20180503125929.ik33sbe2jpa4hpm3@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-es-ayuda |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | gilberto.castillo | 2018-05-03 13:02:48 | Re: [MASSMAIL]Conflicto entre pg_dump y transacción. |
| Previous Message | Federico Pascual | 2018-05-03 12:50:11 | Conflicto entre pg_dump y transacción. |