[source-postgres] Incremental CDC sync fails with "Saved offset is before replication slot's confirmed lsn" after successful snapshot

[melissawessel]

Hi all — I’m testing Postgres CDC on our staging environment and running into an issue I haven’t been able to get past. Hoping someone can help me understand what’s going on or confirm whether this is expected behavior.

I’m using source-postgres with CDC enabled. The initial snapshot sync works fine, but the very next sync (the first incremental CDC run) always fails immediately with:

Saved offset is before replication slot's confirmed lsn

Because of this, I haven’t been able to get a successful incremental CDC sync yet.

What I’m doing

• Created a small test table and publication
• Set up a new Postgres CDC → Snowflake connection
• Ran the initial sync (success)
• Inserted a couple of rows
• Triggered a second sync 30–90 seconds later

The second sync always fails the same way.

One nuance: if I run an incremental sync without making any table changes, the sync succeeds. As soon as I insert/update rows and advance the slot LSN, the next sync fails with the LSN mismatch.

What I’ve tried

• Recreated the replication slot
• Recreated the publication
• Deleted and recreated the source and connection
• Verified Postgres settings (wal_level = logical, max_slot_wal_keep_size = -1)
• Very low write volume (just manual inserts)

Even with a completely fresh setup, the incremental sync fails immediately.

Log excerpt

Here is the relevant part showing the mismatch:

Found previous partition offset ... {lsn=3980442808, ...}
Replication slot confirmed_flush_lsn : 3980444568 Saved offset LSN : 3980442808

ERROR ... Saved offset is before replication slot's confirmed lsn.
at io.airbyte.integrations.source.postgres.cdc.PostgresCdcCtidInitializer.cdcCtidIteratorsCombined(...)
at io.airbyte.integrations.source.postgres.PostgresSource.getIncrementalIterators(...)

Possibly related

I found a GitHub discussion where someone ran into a similar LSN mismatch after switching from wal2json to pgoutput, and the solution was to recreate the connection because the saved CDC state and slot state no longer aligned.
(They mentioned that recreating only the slot wasn’t enough.)

In my case, even recreating the slot, publication, source, and connection doesn’t clear the mismatch, so I’m wondering if something similar could be happening with internal state.

What I’m trying to understand

What I’m trying to understand is why the connector’s saved offset ends up behind the slot’s confirmed_flush_lsn immediately after a fresh snapshot, even with almost no DB activity. Is this expected, or is there something specific I should be configuring to prevent that gap? Any guidance would be appreciated.

[avishaan]

I'm having the same issue