Skip to content

fix: equality deletes written to the wrong partition - #91

Merged
hasyimibhar merged 1 commit into
mainfrom
fix/partition-deletes
Oct 5, 2026
Merged

hasyimibhar merged 1 commit into
mainfrom
fix/partition-deletes

Conversation

@hasyimibhar

@hasyimibhar hasyimibhar commented Oct 5, 2026 •

Copy link
Copy Markdown
Collaborator

This fixes delete_under_default_replica_identity_reaches_the_rows_partition and update_moving_a_row_between_partitions_leaves_no_copy.

Iceberg scopes an equality delete to its own partition. The writer placed each delete by its row payload, which can't say where the row lives:

  • Key-only delete (REPLICA IDENTITY DEFAULT, partition column outside the key): the delete carries NULL for the partition column, lands in the NULL partition, and the deleted row stays in Iceberg.
  • UPDATE moving a row between partitions: the delete of the old version goes to the new partition, so the old row survives and the table holds two copies of the key.

The fix is to put equality deletes (a Delete's, and the delete half of an Update) in the partition the FileIndex has their key in. Unindexed keys fall back to the payload as before.

Iceberg scopes an equality delete to its own partition, but the writer
placed each delete by its row payload. A key-only delete (REPLICA
IDENTITY DEFAULT, partition column outside the key) carries NULL for the
partition column, and an UPDATE's new values can name another partition
than the old row's. Both deletes missed the row they meant to remove:
the deleted row stayed, or the moved row was left in both partitions.

Equality deletes now go to the partition the FileIndex has their key in,
where the row lives, falling back to the payload for unindexed keys.

The DST oracle also checks that every row is stored in the partition its
values compute to: a misplaced row reads back on a full scan, but a query
pruning on the partition column skips it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@hasyimibhar
hasyimibhar merged commit da8ea97 into main Oct 5, 2026
2 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant