Hi Guys, I am trying to run airbyte to load data from postgres to snowflake. So this is the first time I am running to load data from postgres to snwoflake with method as cdc with incremntal | append+dedup and even though no log is generated on that table in the db it failed with below error...any help would be much appreciated ... Sync failed 0 bytes | no records loaded | 10m 49s Warning from source: Something went wrong in the connector. See the logs for more details. Something went wrong in the connector. See the logs for more details. java.lang.RuntimeException: org.postgresql.util.PSQLException: ERROR: requested WAL segment 000000010000000000000006 has already been removed

This error means PostgreSQL has already removed the WAL segment Airbyte needs to continue the CDC sync: >

ERROR: requested WAL segment 000000010000000000000006 has already been removed

When that happens, Airbyte/Debezium can’t read the changes from the point saved in the connector state, so the incremental CDC run fails and must fall back to a full snapshot. [[Postgres troubleshooting](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#troubleshooting)] This typically occurs when: - There were many writes so old WAL files were purged/archived before Airbyte could read them; or - Airbyte had previously acknowledged some WAL but the destination didn’t finish and on retry those WAL segments are already gone. [[Postgres troubleshooting](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#troubleshooting)] To mitigate: 1. Run syncs more frequently so WAL doesn’t need to be kept for so long. [[Postgres troubleshooting](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#troubleshooting)] 2. Increase

wal_keep_size

on Postgres so more WAL is retained (consumes more disk). [[Postgres troubleshooting](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#troubleshooting)] 3. If this happened after a long pause or a heavy-write period, trigger a full refresh in Airbyte to re-establish a valid starting point; subsequent CDC runs should then succeed as long as WAL isn’t purged too quickly. 4. If your database has low write volume and the

confirmed_flush_lsn

is not advancing, consider a heartbeat setup (adding a heartbeat table and Debezium heartbeat query) to keep WAL moving and avoid problematic WAL behavior. [[WAL disk consumption](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#advanced-wal-disk-consumption-and-heartbeat-action-query)] If after doing this the job still fails with the same WAL-removed error, the only documented recovery path is to let Airbyte do a full snapshot (full refresh) so it can start CDC again from a valid LSN. [[Postgres troubleshooting](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#troubleshooting)]

ok but then this is fresh load and no dml operation happend on that table so no log is generaetd then howcome this WAL is removed by postgres if there is no genertaed on that table