Why do some tables won't let you set them as "incr...
# replication-ask-ai
y
Why do some tables won't let you set them as "incremental dedup" mode in the postgres cdc connection?
✅ 1
k
There are a few reasons why some tables may not have the Incremental (or Incremental + Deduped) sync mode available in a Postgres CDC connection: 1. Missing Primary Key (Most Common Reason) CDC incremental sync is only supported for tables that have primary keys. If a table lacks a primary key, Airbyte will only offer Full Refresh sync modes for that table. [CDC Limitations] [Postgres Troubleshooting] > "Incremental sync is only supported for tables with primary keys. For tables without primary keys, use Full Refresh sync." 2. No Valid Cursor Field Even if a table has a primary key, Airbyte also requires at least one column that can be used as a cursor field for standard incremental sync. In some connector versions (around 1.0.3–1.0.10), tables with only nullable columns were incorrectly excluded from incremental mode. This was fixed in connector version 1.0.11. [Postgres source tables] 3. Data in Views, Not Tables If your data is in a view rather than a base table, CDC incremental mode is not supported. You would need to use a non-CDC connection with
Standard
replication method instead. [Postgres Troubleshooting] 4. Partitioned Tables Root partitioned tables in Postgres also have known limitations with CDC incremental sync. Individual partitions may support incremental sync, but the root partitioned table typically does not. [Postgres CDC partitioned tables] In summary, the most likely cause is that the affected tables do not have a primary key, which is required for CDC incremental/deduped sync. Adding a primary key to those tables should resolve the issue. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
y
@kapa.ai The one specific table I'm looking at has primary key and cursor field.
k
Since your table has both a primary key and a cursor field, here are some other potential causes to investigate: Nullable Cursor Column A known bug in Postgres source connector versions 1.0.3–1.0.10 caused tables with nullable cursor columns to be excluded from incremental mode, even if the column had valid values. The fix was released in version 1.0.11. [Postgres source tables] > Upgrading to 1.0.11 or downgrading to 1.0.2 resolved the issue for affected users. Unsupported Cursor Column Type If your cursor column is of type
TIMESTAMP_WITH_TIMEZONE
, it may be flagged as an unsupported cursor type, resulting in an error like:
Copy code
Unsupported cursor type: TIMESTAMP_WITH_TIMEZONE
In this case, consider using a different column type (e.g., plain
TIMESTAMP
or an integer) as your cursor field. [Error with timestamp column] Recommended Steps 1. Check your connector version — upgrade to the latest Postgres source connector version, as many cursor-related bugs have been fixed over time. 2. Check if your cursor column is nullable — even if it has no null values in practice, the column definition itself being nullable may have caused issues in older versions. 3. Check your cursor column's data type — ensure it is a supported type for cursor-based incremental sync. If none of these apply, the knowledge sources don't contain enough information to pinpoint the exact cause in your specific case, and it may be worth opening a support ticket or GitHub issue with your connector version and table schema details. 👍 0 button 👎 0 button â„šī¸ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
m
What version of the connector are you running? Are you sure that the table is included in the publication you're using?
y
Yeah we just added it but still no go. What's weird is we were able to use the increemntal mode at the first sync, so those ones we had originally have been set up incremental. But now we're wanting to add more tables, but can't. The version we're using is Postgres v3.7.2
m
Hmm, strange. Are you on cloud or self-hosted?
y
Self hosted
m
We're about to release source-postgres 3.8.0, which is a complete connector rewrite. You could try version
3.8.0-rc.10
and see if that works.
y
Okay it turns out I need to click on "refresh source schema" button!
m
ah, that'll do it!