I've been struggling with a CDC issue. Error:

Saved offset is before replication slot's confirmed lsn. Please reset the connection, and then increase WAL retention and/or increase sync frequency to prevent this from happening in the future.

Connector:`source-postgres:3.6.35` Setup: Self-hosted Airbyte on Kubernetes → RDS PostgreSQL (CDC via pgoutput) → S3 We have already tried: - Increasing WAL retention to 10 GB. Our peak data volume between syncs is only ~3 GB, so WAL exhaustion was never the real cause - Increased sync frequency to every 1 hour. Didn't help - Set

invalid_cdc_cursor_position_behavior

to

Re-sync data

— this silently masked the error by triggering full refreshes on every failure I am aware that this is a common error among the community. Has anyone manage to find a proper solution? 🙏

Postgres CDC "Saved offset is before replication slot's confirmed LSN" Based on the knowledge sources, this is a well-documented bug introduced in source-postgres v3.6.19 caused by two root issues: Root Causes 1. PgJDBC regression (primary cause): PgJDBC 42.7.0+ (used from connector v3.6.19 onwards) automatically advances

confirmed_flush_lsn

even when there are no new events for the publication tables — but the WAL still contains changes for tables outside the publication. This causes the saved state LSN to fall behind the confirmed flush LSN. [CDC PgJDBC Issue] 2. Wrong LSN committed during initial snapshot:

PostgresCdcCtidInitializer

calls

pg_current_wal_lsn()

multiple times during initialization and commits a higher LSN than what gets saved in the state, creating a mismatch from the very first sync. [Wrong LSN Issue] Status of Your Version (3.6.35) The knowledge sources indicate: • The bug was introduced in v3.6.19 and confirmed present through v3.7.0 • A fix was shipped in v3.6.34 for the wrong LSN commit issue [fix reference] • A preview build

3.7.1-preview.8ed70f5

and then v3.7.2 were reported to resolve the issue [fix confirmed] Since you're on v3.6.35, you may be on a version that includes the v3.6.34 fix, but the knowledge sources don't explicitly confirm whether v3.6.35 fully resolves both root causes. Upgrading to v3.7.2 or later is the most strongly recommended path based on community reports. Actionable Workarounds (if you can't upgrade immediately) 1. Set up a heartbeat table (most effective workaround) This ensures the publication always has activity, preventing the PgJDBC regression from advancing

confirmed_flush_lsn

incorrectly:

-- Create the heartbeat table
CREATE TABLE public.airbyte_heartbeat (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
    text TEXT
);

-- Add it to your publication
ALTER PUBLICATION <publicationName> ADD TABLE public.airbyte_heartbeat;

Then in the Airbyte Postgres source connector under Advanced → Debezium heartbeat query, set:

INSERT INTO public.airbyte_heartbeat (text) VALUES ('heartbeat')

This keeps the LSN advancing within the publication, preventing the mismatch. [Heartbeat Fix] 2. Add a high-traffic table to the publication (read-only alternative) If you don't want to give Airbyte write access:

ALTER PUBLICATION <publicationName> ADD TABLE <high_volume_table>;

You don't need to sync this table — just having it in the publication advances the LSN. [WAL Disk Consumption] 3. Downgrade to v3.6.18 (last known stable version) Multiple community members confirmed v3.6.15 and v3.6.18 are unaffected. This is a regression workaround only — you'd lose recent connector improvements. [Downgrade Workaround] Summary Given you're already on v3.6.35, upgrading to v3.7.2+ combined with the heartbeat table setup is the most robust long-term solution based on community experience. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements