How to Fix XMIN Issues

1min
When no logical replication slot is enabled/existing, XMIN is the default to allow change data capture incremental update concepts to work out of the box.
If you encounter an issue with XMIN replication this is most likely ue to PostgreSQL's internal vacuuming process where too much time has lapsed since the last successful synchronization of data. We see this most often when the autovacuum_freeze_max_age is set to a low value or and/or the Sync Bridge frequency is not set high enough for the amount of data transactions on the source database.
Resolution:
If this is the case for your Sync Bridge data source or you receive an alert regarding this, we recommend the one or all of the options below:
Increase the autovacuum_freeze_max_age value on the PostgreSQL database server
Run the vacuum freeze command on the database server
FYI, the XMIN process in the PostgreSQL database server tracks each transaction in a table with a unique id number, and technically when it reaches the value of the autovacuum_freeze_max_age (the default value is 200M transactions), the server will mark/classify those existing records XMIN id as old records. By running explicitly vacuum freeze it basically allows the process to start over for transactions count. 
Switch to a Test Decoding Replication Setup﻿ instead of XMIN for how change tracking of incremental changes is handled
﻿
FAQ : PostgreSQL
How to Fix Replication Slot Performance or Errors?