Re: [MASSMAIL]Conflicto entre pg_dump y transacción.

Si, ello evitaría ese error,

En mi caso tengo varios nodos, te aclaro, dejo pasar pocas query al
master, para ello uso a los esclavos. Es como llego a ese compromiso de
balanceo; si así se le pudiera llamar ;-)))

On 2018-05-03 09:10, Federico Pascual wrote:
> Gilberto,
> Hola. Gracias por responder.
> Con eso evitaría este error?
> Actualmente estoy haciendo el bkup físico en el maestro y el lógico
> en el slave. La idea era distribuir la carga.
>
> Saludos.
>
> El 3 de mayo de 2018, 10:02, <gilberto(dot)castillo(at)etecsa(dot)cu> escribió:
>
>> Hola Federico,
>>
>> Hasta donde entiendo del tema, en un esquema master-esclavos, todas
>> la tarea de mantenimientos las debes hacer en el master, el se
>> encargará de actualizar sus dependencias.
>>
>> Saludos,
>> Gilberto Castillo
>>
>> On 2018-05-03 08:50, Federico Pascual wrote:
>>
>>> Buenas gente.
>>>
>>> Les consulto por el siguiente problema.
>>>
>>> En un servidor esclavo (síncrono) Postgres 9.1 se realiza un bkup
>>> lógico en forma diaria de distintas dbs y esquemas.
>>>
>>> Cada tanto, el bkup de UN esquema en particular (la realización
>>> del
>>> mismo), falla.
>>>
>>> El comando utilizado para la realización del bkup es el
>>> siguiente:
>>>
>>> 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.
>>> 2018-05-02 20:13:39 GMT+3 postgres stg SENTENCIA: COPY
>>> otrs.ticket_history (id, name, history_type_id, ticket_id,
>>> article_id,
>>> type_id, queue_id, owner_id, priority_id, state_id, valid_id,
>>> create_time, create_by, change_time, change_by) TO stdout;
>>> 2018-05-02 20:13:39 GMT+3 postgres stg FATAL: terminando la
>>> conexión
>>> 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.
>>> 2018-05-02 20:13:39 GMT+3 postgres stg HINT: Dentro de un momento
>>> debería poder reconectarse y repetir la consulta.
>>>
>>> De lo anterior entiendo que hay algún conflicto entre la tarea
>>> del
>>> dump y alguna operación realizada en alguna transacción
>>> (eliminación, actualización?).
>>>
>>> No se supone que un dump no puede entrar en conflicto con una
>>> transacción?
>>>
>>> El pg_dump no toma el estado consistente al momento de iniciarse?
>>>
>>> El pg_dump puede ejecutarse en caliente?
>>>
>>> He buscado información al respecto pero solo encuentro
>>> referencias a
>>> la traducción del mensaje de error.
>>>
>>> Saludos y gracias por cualquier información.
>>>
>>> Federico.