Skip to content

Conversation

@andrwng
Copy link
Contributor

@andrwng andrwng commented Aug 25, 2025

Glue doesn's support the purgeRequested option when dropping tables, and
will reject our requests indefinitely when a tombstone exists. This ends
up blocking topic tombstone removal, and therefore blocks subsequent
Iceberg topics of the same name from translating any data.

This commit plumbs a bool to the drop_table() command that is false for
Glue.

I considered doing this in the catalog layer, but opted to be more
explicit (it's hopeflly less surprising for readers that way).

Manually tested this against Glue:

  1. create an Iceberg topic
  2. produce to the Iceberg topic and wait for Iceberg commits
  3. drop the Iceberg topic
  4. witness the drop table op eventually succeeding in Glue
  5. manually delete the data in Iceberg
  6. recreate the topic and produce without issues

...as well as another sequence where I didn't do step 4 and instead
immediately went on to delete data and recreate the topic. In both
cases, the Redpanda coordinator was not blocked and could produce to the
new topic without issues.

Kludge for https://redpandadata.atlassian.net/browse/CORE-13087

Backports Required

  • none - not a bug fix
  • none - this is a backport
  • none - issue does not exist in previous branches
  • none - papercut/not impactful enough to backport
  • v25.2.x
  • v25.1.x
  • v24.3.x

Release Notes

Bug Fixes

  • Redpanda will now automatically detect when using the Glue Iceberg REST Catalog and avoid using the purgeRequested=true option when dropping tables. This would previously result in commits to Iceberg being blocked when an Iceberg topic was deleted and recreated.

We'll need another kludge for Glue (to not purge tables when dropping,
which isn't currently supported by Glue), so this pulls out the
Glue-detecting logic for reuse in a subsequent commit.
Glue doesn's support the purgeRequested option when dropping tables, and
will reject our requests indefinitely when a tombstone exists. This ends
up blocking topic tombstone removal, and therefore blocks subsequent
Iceberg topics of the same name from translating any data.

This commit plumbs a bool to the drop_table() command that is false for
Glue.

I considered doing this in the catalog layer, but opted to be more
explicit (it's hopeflly less surprising for readers that way).

Manually tested this against Glue:
1. create an Iceberg topic
2. produce to the Iceberg topic and wait for Iceberg commits
3. drop the Iceberg topic
4. witness the drop table op eventually succeeding in Glue
5. manually delete the data in Iceberg
6. recreate the topic and produce without issues

...as well as another sequence where I didn't do step 4 and instead
immediately went on to delete data and recreate the topic. In both
cases, the Redpanda coordinator was not blocked and could produce to the
new topic without issues.
@andrwng andrwng changed the title dl/coordinator: don't purge data when dropping Glue table [CORE-13087] dl/coordinator: don't purge data when dropping Glue table Aug 25, 2025
@andrwng andrwng merged commit 2b82843 into redpanda-data:dev Aug 26, 2025
20 checks passed
@vbotbuildovich
Copy link
Collaborator

/backport v25.2.x

@vbotbuildovich
Copy link
Collaborator

/backport v25.1.x

@vbotbuildovich
Copy link
Collaborator

Failed to create a backport PR to v25.1.x branch. I tried:

git remote add upstream https://github.com/redpanda-data/redpanda.git
git fetch --all
git checkout -b backport-pr-27367-v25.1.x-794 remotes/upstream/v25.1.x
git cherry-pick -x 60093e7213 dac352433a

Workflow run logs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants