## Issue: Persistent Temp Table After Second Sync

[SRDChivukula]

Hi everyone, I'm running Airbyte Cloud: Airtable → Postgres (Supabase). Sync mode is Full Refresh | Overwrite + Deduped.

Setup:

• Airbyte source: Airtable connector v4.6.24
• Airbyte destination: destination-postgres v3.0.11 (Direct Load architecture)
• Supabase on Postgres 17.6.1, AWS us-east-1
• Connection: Supabase Session Pooler, port 5432 ( As Airbyte Cloud is on GCP (IPv4) and Supabase's direct connection is IPv6-only.

Issue: Temp table persists after second sync
-Sync 1: Works correctly. Airbyte creates a temp table, loads data, renames it to the final table. Only one clean table exists in the destination schema.
-Sync 2: A second table appears, with the schema name prepended to the stream name:

crm_appSxmtb5nHyf9HCK_email_template_tblUXl41Q2spp66IJ (final table)
testingcrm_appSAU7BeCUOc82b2f1c12834b9a1b41679cd38546cc (temp table persisting)

The second table follows the pattern {schema_name}{stream_name}{UUID}, which looks like the staging temp table Airbyte creates during the atomic swap for Full Refresh Overwrite.

• Syncs 3, 4, 5+: No additional tables are created. The same two tables persist indefinitely.
• Manually dropping the temp table: It gets recreated on the very next sync.
• Both tables have identical row counts and columns

What I've already ruled out:

• Stream Prefix is empty
• Destination Namespace is set to Destination Default
• airbyte_internal schema exists but is completely empty (expected for v3.0.11 Direct Load)
• Changing SSL mode from disable to require does not resolve it
• All syncs show fully green/successful in the Timeline

CONFIRMED FROM LOGS (job 76039023):

--- CATALOG INIT (line 74) ---
Airbyte explicitly knows two tables exist:tempTableName=testingcrm_appSAU7BeCUOc82b2f1c12834b9a1b41679cd38546cc ← old temp from previous sync
finalTableName=crm_appSxmtb5nHyf9HCK_email_templates_tbl4ear1HAU7BeCUO

--- INIT QUERIES (lines 82-83) ---
SELECT COUNT() FROM "testing"."crm_appSxmtb5nHyf9HCK_email_templates_tbl4ear1HAU7BeCUO";SELECT COUNT() FROM "testing"."testingcrm_appSAU7BeCUOc82b2f1c12834b9a1b41679cd38546cc"; → Airbyte reads the old temp table, confirming it is aware of its existence

--- ATOMIC SWAP (lines 260-263) ---
BEGINTRANSACTION; DROP TABLE IF EXISTS"testing"."crm_appSxmtb5nHyf9HCK_email_templates_tbl4ear1HAU7BeCUO"; ALTER TABLE"testing"."testingtestingcd38546cc480f17a30a02dda9791ac654c2425960" RENAME TO"crm_appSxmtb5nHyf9HCK_email_templates_tbl4ear1HAU7BeCUO"; COMMIT;

→ New temp table correctly renamed to final table → OLD temp table (testingcrm_appSAU7BeCUOc82b2f1c12834b9a1b41679cd38546cc) is NEVER dropped — no DROP statement exists for it anywhere in the logs

Questions:

1. Is Temp table cleanup step failing after the atomic rename a connector bug?
2. Could the Session Pooler of Supabase be interrupting the DDL sequence — specifically treating the ALTER TABLE RENAME and the subsequent DROP TABLE as separate transactions, causing the DROP to never execute?
3. Will purchasing Supabase's IPv4 add-on to enable a direct connection (bypassing the pooler entirely) resolve this?