developer-rpai commented on PR #18330: URL: https://github.com/apache/iceberg/pull/18330#issuecomment-6031430520
I think you are right on the recovery angle. Once upsert records are in the checkpoint, this guard fires on every restore and no config change digs the job out — the only exits are state surgery or a restart without state. Fail-fast at commit time is still strictly better than silently dropping deletes, which is what this PR fixes, but the durable answer is what you suggest: validate at the writer, rejecting upsert-mode records when overwrite is enabled before anything lands in checkpointed state. Then a config fix plus a clean restart recovers. Worth filing that as a follow-up issue — this parity guard is the right immediate step and the ingress check builds on it. On duplication: overwrite(false) with upsert goes through the normal row-delta path, same as the static sink's upsert mode, so no duplication beyond ordinary upsert semantics. The genuinely murky case is flipping modes mid-stream to escape the trap, which early validation would prevent in the first place. -- 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]
