liucao-dd commented on PR #18008: URL: https://github.com/apache/iceberg/pull/18008#issuecomment-6697235421
@huaxingao @singhpk234 gentle bump on this again. We are happy to contribute the fix, just need some direction on which approach is preferable. Thank you! > Actually I just saw related discussion on #18348 > > @huaxingao @singhpk234, I would like your opinion on the direction for this fix. > > At the moment, prepareForTriggerAvailableNow() computes the cap from initialOffset. Iceberg writes that offset once, i.e. when the query starts for the first time, and never updates it. When retention expires that snapshot, the computation fails. > > I propose that the cap use the real start offset, i.e. prepareForTriggerAvailableNow() sets a flag only. The first latestOffset(startOffset, limit) call computes the cap. Spark gives the committed start offset in that call. > > Spark Kafka ([KafkaMicroBatchStream](https://github.com/apache/spark/blob/master/connector/kafka-0-10-sql/src/main/scala/org/apache/spark/sql/kafka010/KafkaMicroBatchStream.scala)) uses this pattern. Delta changed to this pattern in [29d3a09](https://github.com/delta-io/delta/commit/29d3a09289f5d799714df448ea9818d2fb5fcdd7), because it ran into similar issues. > > A smaller option is to use latestValidSnapshotOffset() from #18348 as the cap, and not read initialOffset. This option keeps the eager design. It also gives a cap that the planner can reach. > > Which direction do you prefer? -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
