Re: Replicacion con Postgres 10

Todos los cambios son replicados sin problemas hasta que force un conflicto.
> Di de alta un registro en la base de datos que tiene la suscripcion y
> despues lo di de alta en la publicacion.
> El log me indica que la llave ya existe (el registro existe) y por lo
> tanto se detiene la replicacion.
>
> Mis preguntas son:
>
> 1) ¿Tengo alguna funcion o consulta que me permita detectar los conflictos
> sin mirar el log?
>

No, solo es posible ver si hay conflictos desde SQL, pero no ver _que_
conflicto hay.

> 2) ¿Como hago para que continue la replicacion?
> La respuesta simple es eliminar el registro que de la suscripcion.
> Pero queria ver si se podia saltear la instruccion o algo parecido.
> Encontre esta funcion pg_replication_origin_advance(*node_name* text,
> *lsn* pg_lsn)
> <https://www.postgresql.org/docs/devel/static/functions-admin.html#pg-replication-origin-advance>
> pero no se como pasar el parametro lsn.
> Probe con este formato pg_replication_origin_status('tdf'::text,
> '0/31CFECD8'::pg_lsn) y me tira el error
> "no existe la función pg_replication_origin_status(text, pg_lsn)"
>

No hay funciones que permitan extraer el siguiente LSN al registro que
corrompe. Lo que se puede
hacer es consumir el cambio y no aplicarlo (esto se podría hacer
manualmente). Puedes testear esto
con peek en lugar de get (el 1 es la cantidad de cambios, el NULL es porque
no tenemos el LSN de la
siguiente transacción). Una vez que veas que los cambios son "omitibles",
consumes con get:

select pg_logical_slot_peek_changes('s_data',NULL,1);

Respecto a pg_replication_origin_status, como ha dicho Jaime, es una vista.
No hay una forma friendly

para obtener el LSN siguiente, pero es mejor que lo pienses como un sistema
de consumer en su lugar.

Si haces un get vacío puedes descartar el cambio.

--
--
Emanuel Calvo
root en Ayres Data Team
Consultant at Ongres