website logo
⌘K
Getting Started 🚀
What is DataLakeHouse.io?
Our Business-Value Focus
Learn the Basic Concepts
Connectors
Operations Applications
Toast
Asana
Aloha POS
BILL
Bloom Growth
Bullhorn
Ceridian Dayforce
ConnectWise
Facebook Ads
Food Delivery Service Connector
Google Analytics 4
Harvest
Hubspot
Jira
MailChimp
McLeod Transportation
NetSuite (Oracle NetSuite)
Optimum HRIS
Oracle EBS
Oracle PeopleSoft
QuickBooks Online
Salesforce
Shopify
Square
Square Marketplace
Stripe
TriNet
Verizon Wireless Business
Workday HCM
Xero
Zoom
Databases
Files & Object Storage
SSH Tunnel Setup for Hosted Database Systems
Databases FAQ
SQL Transformations
Terraform: Reverse Terraforming
DBT Cloud Transformations
Sync Bridge (Data Pipelines)
Create a Sync Bridge
Manually Run a Sync Bridge
Deleting a Sync Bridge
Historical Re-sync
Analytics
Access Analytics
Snowflake Usage Analytics
Data Catalog
Create the Catalog
Populate the Catalog
Access the Catalog
Data Warehouse Clouds
Snowflake
Open Source DW Models
Alerts & Notifications
Slack Notifications
Untitled doc
Logs & Monitoring
Security
Callback Links
Service Level Agreement (SLA)
Release Notes
May 2023
April 2023
Q3 2022
Q4 2022
Community Overview
Contributor Agreements
Code Contribution Guide
About
License
Viewpoint
Docs powered by archbee 

How to Fix XMIN Issues

2min

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:

  1. Increase the autovacuum_freeze_max_age value on the PostgreSQL database server
  2. Run the vacuum freeze command on the database server
    1. 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.
  3. Switch to a Logical Replication Setup instead of XMIN for how change tracking of incremental changes is handled



Updated 23 May 2023
Did this page help you?
Yes
No
PREVIOUS
FAQ : PostgreSQL
NEXT
How to Fix Replication Slot Performance or Errors?
Docs powered by archbee 
TABLE OF CONTENTS
Resolution: