Hi all! We’re seeing repeated Postgres CDC slot invalidations and would appreciate help determining whether this is a connector checkpointing issue. Setup/behavior: • Postgres source

3.8.5

→ BigQuery, PostgreSQL

18.1

on Cloud SQL,

After loading Data in the destination

,

initial_waiting_seconds=2400

, and

max_slot_wal_keep_size=3 TiB

. We also have a working heartbeat-table upsert every 10 seconds. • The connection alternates between empty syncs and large bursts. One job spent 40 minutes searching for its saved WAL position, received 238 heartbeat events, emitted no records, and ended with

HEARTBEAT_NOT_PROGRESSING

. The next job found the same position after 17 minutes and emitted 3.72M records, but committed zero state before the slot was invalidated. • WAL is generated at approximately 173–190 GB/hour, while the decoded LSN advances at 507–545 GB/hour. However,

restart_lsn

barely advances, so retained WAL eventually exceeds 3 TiB. Should long CDC jobs commit intermediate destination-acknowledged checkpoints? Is there a safe way to advance

confirmed_flush_lsn

during long jobs while retaining “After loading” safety? Could this be related to issue #70887, and is there a recommended patch or configuration?