LuciferYang opened a new issue, #10937: URL: https://github.com/apache/paimon/issues/10937
### Search before asking - [X] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar. ### Paimon version master (30d91278af) ### Compute Engine Spark ### Minimal reproduce step ```sql CREATE TABLE t (id INT, v STRING) TBLPROPERTIES ( 'row-tracking.enabled' = 'true', 'data-evolution.enabled' = 'true', 'deletion-vectors.enabled' = 'true', 'write-buffer-for-append' = 'true', 'write-buffer-size' = '256 kb', 'page-size' = '64 kb' ); INSERT INTO t SELECT /*+ REPARTITION(1) */ id, concat(repeat('x', 200), id) FROM range(0, 5000); INSERT INTO t SELECT /*+ REPARTITION(1) */ id, concat(repeat('x', 200), id) FROM range(5000, 10000); DELETE FROM t WHERE id % 1000 = 0; CALL sys.compact(table => 't', options => 'compaction.min.file-num=2'); ``` `CALL sys.materialize_deletion_vectors(table => 't', options => 'compaction.min.file-num=2')` fails the same way. The small `write-buffer-size` only makes the buffer spill quickly; with the default size the same happens once the rows of one compaction task exceed 256 MB. ### What doesn't meet your expectations? The compaction fails: ``` java.lang.NullPointerException at org.apache.paimon.disk.ExternalBuffer.spill(ExternalBuffer.java:148) at org.apache.paimon.disk.ExternalBuffer.put(ExternalBuffer.java:122) at org.apache.paimon.utils.SinkWriter$BufferedSinkWriter.write(SinkWriter.java:168) at org.apache.paimon.append.AppendOnlyWriter.write(AppendOnlyWriter.java:216) at org.apache.paimon.append.dataevolution.DataEvolutionNormalCompactTask.doCompact(DataEvolutionNormalCompactTask.java:151) at org.apache.paimon.spark.procedure.DataEvolutionRewriteExecutor.lambda$execute$40cbfc52$1(DataEvolutionRewriteExecutor.java:171) ``` `DataEvolutionNormalCompactTask` and `DataEvolutionMaterializeDeletionCompactTask` create their writer with `AppendFileStoreWrite.createWriter` and never set an `IOManager`. With `write-buffer-for-append = true` the append writer keeps rows in a spillable buffer (`write-buffer-spillable` is true by default), and the first spill calls `createChannel()` on the null `IOManager`. Only the split-large-files branch of the normal task turns the buffer off today. ### Anything else? _No response_ ### Are you willing to submit a PR? - [X] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
