Drop the SQL issue when attempting to drop an Iceberg table whose location does not exist
Apache Iceberg version
1.2.0 (latest release)
Query engine
Spark
Please describe the bug 🐞
When executing a DROP SQL on an Iceberg table where the table location does not exist, it throws the following exception:
Location does not exist: s3a://<bucket>/<key-path>/metadata/00001-06c101d1-ef87-4c55-bfe3-8bf4332cff26.metadata.json
org.apache.iceberg.exceptions.NotFoundException: Location does not exist: s3a://<bucket>/<key-path>/metadata/00001-06c101d1-ef87-4c55-bfe3-8bf4332cff26.metadata.json
at org.apache.iceberg.aws.s3.S3InputStream.openStream(S3InputStream.java:193)
at org.apache.iceberg.aws.s3.S3InputStream.positionStream(S3InputStream.java:176)
at org.apache.iceberg.aws.s3.S3InputStream.read(S3InputStream.java:106)
at org.apache.iceberg.shaded.com.fasterxml.jackson.core.json.ByteSourceJsonBootstrapper.ensureLoaded(ByteSourceJsonBootstrapper.java:539)
at org.apache.iceberg.shaded.com.fasterxml.jackson.core.json.ByteSourceJsonBootstrapper.detectEncoding(ByteSourceJsonBootstrapper.java:133)
at org.apache.iceberg.shaded.com.fasterxml.jackson.core.json.ByteSourceJsonBootstrapper.constructParser(ByteSourceJsonBootstrapper.java:256)
at org.apache.iceberg.shaded.com.fasterxml.jackson.core.JsonFactory._createParser(JsonFactory.java:1655)
at org.apache.iceberg.shaded.com.fasterxml.jackson.core.JsonFactory.createParser(JsonFactory.java:1083)
at org.apache.iceberg.shaded.com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3666)
at org.apache.iceberg.TableMetadataParser.read(TableMetadataParser.java:267)
at org.apache.iceberg.TableMetadataParser.read(TableMetadataParser.java:260)
at org.apache.iceberg.BaseMetastoreTableOperations.lambda$refreshFromMetadataLocation$0(BaseMetastoreTableOperations.java:186)
at org.apache.iceberg.BaseMetastoreTableOperations.lambda$refreshFromMetadataLocation$1(BaseMetastoreTableOperations.java:205)
at org.apache.iceberg.util.Tasks$Builder.runTaskWithRetry(Tasks.java:402)
at org.apache.iceberg.util.Tasks$Builder.runSingleThreaded(Tasks.java:212)
at org.apache.iceberg.util.Tasks$Builder.run(Tasks.java:196)
at org.apache.iceberg.util.Tasks$Builder.run(Tasks.java:189)
at org.apache.iceberg.BaseMetastoreTableOperations.refreshFromMetadataLocation(BaseMetastoreTableOperations.java:205)
at org.apache.iceberg.BaseMetastoreTableOperations.refreshFromMetadataLocation(BaseMetastoreTableOperations.java:182)
at org.apache.iceberg.BaseMetastoreTableOperations.refreshFromMetadataLocation(BaseMetastoreTableOperations.java:177)
at org.apache.iceberg.hive.HiveTableOperations.doRefresh(HiveTableOperations.java:251)
at org.apache.iceberg.BaseMetastoreTableOperations.refresh(BaseMetastoreTableOperations.java:100)
at org.apache.iceberg.BaseMetastoreTableOperations.current(BaseMetastoreTableOperations.java:83)
at org.apache.iceberg.BaseMetastoreCatalog.loadTable(BaseMetastoreCatalog.java:44)
at org.apache.iceberg.spark.SparkCatalog.load(SparkCatalog.java:819)
at org.apache.iceberg.spark.SparkCatalog.loadTable(SparkCatalog.java:159)
at org.apache.iceberg.spark.SparkSessionCatalog.loadTable(SparkSessionCatalog.java:138)
at org.apache.spark.sql.connector.catalog.CatalogV2Util$.loadTable(CatalogV2Util.scala:311)
In this case, the Iceberg table still exists in the metastore, and we need a way to drop it from the metastore.
It is possible to do this without configuring spark_catalog with SparkSessionCatalog or SparkCatalog. However, it is still required even if the spark catalog is configured.
This issue has been automatically marked as stale because it has been open for 180 days with no activity. It will be closed in next 14 days if no further activity occurs. To permanently prevent this issue from being considered stale, add the label 'not-stale', but commenting on the issue is preferred when possible.
I've just hit this issue. I see there are two open PRs to resolve this: #7228 and #6786. My two cents is that modifying the behaviour of DROP TABLE to succeed even if the metadata is missing is the right fix.
Hi all, I hit same issue. Any idea how to get the workaround and drop the table before the fixed PR is released? Thanks!
This issue has been automatically marked as stale because it has been open for 180 days with no activity. It will be closed in next 14 days if no further activity occurs. To permanently prevent this issue from being considered stale, add the label 'not-stale', but commenting on the issue is preferred when possible.
This issue has been closed because it has not received any activity in the last 14 days since being marked as 'stale'