Lo que realmente desea es la descodificación lógica de PostgreSQL 9.4. soporte, que le permite extraer un flujo de cambios del servidor Para usarlo, necesita un complemento de decodificación lógica que convierta el flujo de cambios en el servidor en algo que su aplicación pueda consumir. Hay varios en desarrollo, pero aún es muy temprano.
Dado que notó en un comentario que está utilizando AWS RDS, en este momento no tiene suerte, ya que RDS en el momento de escribir este artículo no ofrece complementos de decodificación y necesitaría privilegios de superusuario para instalarlos.
No puede usar xmin y xmax para una copia incremental completa, porque no puede hacer lecturas sucias en PostgreSQL, por lo que no puede ver si una tupla ha sido DELETE d. Para usar ID de transacción, debe evitar VACUUM de eliminar filas "muertas", es decir, filas que ninguna transacción actual todavía necesita para realizar correctamente. También necesitaría poder hacer lecturas sucias. Ninguno de ellos tiene soluciones fáciles en PostgreSQL.
Si tiene tablas de solo inserción (o realiza inserciones y actualizaciones, nunca elimina y nunca cambia la clave principal de una fila), entonces posiblemente pueda usar la transacción xmin. Tendrá que lidiar con transaction-id wraparound
revisando pg_database.datfrozenxid y pg_class.relfrozenxid por la relación de interés. Consulte el código fuente y los comentarios en el código para obtener más detalles. VACUUM y la falta de lecturas sucias no es un problema si nunca elimina una entrada, ya que no necesita ver las filas "desaparecidas".
Use la decodificación lógica en 9.4+ si es posible. Para versiones anteriores, si necesita una replicación completa, debe acumular una cola de cambios con disparadores.
Si puede prohibir las eliminaciones y los cambios de clave principal por completo, puede usar xmin para encontrar filas modificadas, siempre que se asegure de que no haya delete s ejecutar, o cualquier update s que cambian primary key s.
