Wat je echt wilt is PostgreSQL 9.4's logische decodering ondersteuning, waarmee u een wijzigingsstroom kunt extraheren van de server. Om het te gebruiken, heb je een logische decoderingsplug-in nodig die de wijzigingsstroom op de server verandert in iets dat je app kan consumeren. Er zijn er een aantal in ontwikkeling, maar het is nog vrij vroeg.
Aangezien je in een opmerking hebt opgemerkt dat je AWS RDS gebruikt, heb je op dit moment pech, aangezien RDS op het moment van schrijven geen decoderingsplug-ins biedt en je superuser-rechten nodig hebt om ze te installeren.
Je kunt xmin en xmax niet gebruiken voor volledig incrementeel kopiëren, omdat je geen vuile reads kunt doen in PostgreSQL, dus je kunt niet zien of een tuple is DELETE d. Om transactie-ID's te gebruiken, moet u voorkomen dat VACUUM van het verwijderen van "dode" rijen, d.w.z. rijen die geen enkele huidige transactie nog correct moet uitvoeren. Je moet ook in staat zijn om dirty reads te doen. Geen van beide heeft gemakkelijke oplossingen in PostgreSQL.
Als u alleen tabellen invoegen . heeft (of u voegt in en werkt bij, verwijdert nooit en wijzigt nooit de primaire sleutel van een rij) dan kunt u eventueel de transactie xmin gebruiken. U zult te maken krijgen met transaction-id wraparound
door pg_database.datfrozenxid . aan te vinken en pg_class.relfrozenxid voor de belangenrelatie. Zie de broncode en opmerkingen in de code voor details. VACUUM en het ontbreken van vuile lezingen is geen probleem als u nooit een item verwijdert, omdat u geen "verdwenen" rijen hoeft te zien.
Gebruik indien mogelijk logische decodering in 9.4+. Voor oudere versies, als u volledige replicatie nodig heeft, moet u een wijzigingswachtrij met triggers verzamelen.
Als u verwijderingen en primaire sleutelwijzigingen volledig kunt verbieden, kunt u xmin . gebruiken om gewijzigde rijen te vinden, zolang u ervoor zorgt dat er geen delete . zijn s run, of een update s die primary key change wijzigen v.