@kapa.ai suddenly most of my connections are giving this error Failure in source: 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. See https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#under-cdc-incremental-mode-there-are-still-full-refresh-syncs for more details. source connector is Postgres v3.7.2 and destination connector is Postgres v3.0.7

The error "Saved offset is before replication slot's confirmed LSN" means that the WAL position Airbyte saved in its state is behind the

confirmed_flush_lsn

of the replication slot — so Postgres has already advanced past what Airbyte thinks it last read. [Postgres troubleshooting] Root Causes There are two main causes documented for this: 1. WAL purged by Postgres – When there are many DB updates, Postgres purges WAL files. Airbyte's saved offset then points to a position that no longer exists. [Postgres troubleshooting] 2. PgJDBC regression (versions ≥ 3.6.19) – Starting from connector version 3.6.19, PgJDBC 42.7.0+ was introduced, which automatically advances

confirmed_flush_lsn

even when there are no new events for the publication tables (but the WAL contains changes for tables outside the publication). This causes the saved state LSN to fall behind the confirmed flush LSN. [CDC LSN issue] Good News for v3.7.2 According to community reports in the GitHub issue tracker, version 3.7.2 was released specifically to fix this LSN mismatch issue: > "Airbyte released

3.7.2

which fixes this issue for me" [CDC LSN issue] Since you're already on 3.7.2 and still seeing the error, the issue may be that your connections have a corrupted/stale saved state from before the fix was applied. Recommended Steps 1. Reset the affected connections – As the error message itself suggests, reset the connection to clear the bad saved state and start a fresh sync. 2. Set up a heartbeat table – For low-traffic tables, the LSN can drift because there are no publication events to advance it. Setting up a heartbeat table helps keep the LSN advancing: [WAL heartbeat fix]

CREATE TABLE airbyte_heartbeat (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
    text TEXT
);

ALTER PUBLICATION <publicationName> ADD TABLE airbyte_heartbeat;

Then configure the Debezium heartbeat query in the Postgres source connector:

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

3. Increase sync frequency – Running syncs more often reduces the chance of WAL being purged between runs. [Postgres troubleshooting] 4. Increase

wal_keep_size

on the Postgres server to retain more WAL segments. [Postgres troubleshooting] 5. Check

Invalid CDC position behavior

– If you set this to

Re-sync data

instead of

Fail sync

, Airbyte will automatically perform a full refresh when this condition is detected, rather than failing. Note this may be costly for large tables. [CDC LSN issue] If the issue persists after resetting connections on v3.7.2, it may be worth checking the open GitHub issue #55846 for further updates. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

I'm already did an upgrade Postgres connector to v3.7.2 @kapa.ai

Since you're already on v3.7.2, the fix for the PgJDBC LSN regression should be in place. However, your connections likely still have a stale/corrupted saved state from before the upgrade, which is why the error persists. Here's what to do: 1. Reset each affected connection in the Airbyte UI. This clears the bad saved offset and forces a fresh sync. The error message itself instructs this, and it's the most direct fix for connections carrying over a broken state. 2. Set up a heartbeat table if your publication tables have low traffic — this is the most reliable long-term prevention. [WAL heartbeat fix]

CREATE TABLE airbyte_heartbeat (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP NOT NULL DEFAULT current_timestamp,
    text TEXT
);

ALTER PUBLICATION <publicationName> ADD TABLE airbyte_heartbeat;

Then set the Debezium heartbeat query in the source connector settings to:

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

3. If resetting connections doesn't resolve it, there is also a known (still open) issue where clearing a connection may not fully reset the state if it retains stream states from previously synced tables. In that case, deleting and recreating the connection entirely has been reported as the only reliable fix. [state reset issue] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai anything to change in the connection state json { "shared_state": { "state": { "[\"nawy-shares\",{\"server\":\"nawy-shares\"}]": "{\"lsn_proc\":559907118608,\"messageType\":\"INSERT\",\"lsn_commit\":559907096528,\"lsn\":559907118608,\"txId\":1350079,\"ts_usec\":1777374111968403}" } }, "streamStates": [] }

Looking at your connection state JSON, the key value to focus on is the

lsn

(or

lsn_commit

) field in the shared state. The error occurs when this saved LSN is behind the

confirmed_flush_lsn

of your replication slot. What to Check First Run this query on your Postgres database to compare:

SELECT 
  slot_name,
  confirmed_flush_lsn,
  confirmed_flush_lsn - '0/0'::pg_lsn AS numeric_confirmed_flush_lsn
FROM pg_replication_slots
WHERE slot_type = 'logical';

Compare the

numeric_confirmed_flush_lsn

result with your saved

lsn

value (

559907118608

). If

numeric_confirmed_flush_lsn

>

559907118608

, that confirms the mismatch. Fixing the State The Airbyte documentation allows you to manually edit the connection state to resolve this without a full reset: [Manage connection state] 1. Go to Connections → select the affected connection → Settings tab → Advanced dropdown → Connection State. 2. Update the

lsn

value in the shared state to match (or slightly exceed) the

confirmed_flush_lsn

numeric value from the query above. Your updated JSON would look like:

{
  "shared_state": {
    "state": {
      "[\"nawy-shares\",{\"server\":\"nawy-shares\"}]": "{\"lsn_proc\":<new_lsn>,\"messageType\":\"INSERT\",\"lsn_commit\":<new_lsn>,\"lsn\":<new_lsn>,\"txId\":1350079,\"ts_usec\":1777374111968403}"
    }
  },
  "streamStates": []
}

Replace

<new_lsn>

with the numeric value of

confirmed_flush_lsn

from your replication slot. > ⚠️ Important caveat from Airbyte docs: "Updates to connection state should be handled with extreme care. Updates may break your syncs, requiring a full historical sync of your data to fix. Make changes only as directed by the Airbyte team." [Manage connection state] One user in the GitHub issue reported that manually updating the state to the

confirmed_flush_lsn

value made the next sync work, but the issue returned on the sync after that — suggesting this is a temporary fix unless the underlying LSN advancement problem is also addressed (e.g., via a heartbeat table). [CDC LSN issue] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Hi @Amal Mokhtar. Are you on airbyte cloud, or self hosted? One more thing to check out - make sure you're not using the same replication slot for multiple connections.

hello @Matt Bayley! Thanks for reaching out. I'm not using the same replication slot for different connections. I ended up re-writing the connection state myself to do a full refresh. Bc doing a full refresh through UI was causing errors as well and wasn't working. And so far, everything seems to be stable.