jx2lee commented on issue #1015: URL: https://github.com/apache/iceberg-go/issues/1015#issuecomment-6685348967
I'd like to add a user-side data point in favor of flipping the default to `4`. Many people who reach for iceberg-go already run Java or PyIceberg writers against same tables. Both of those retry commit conflicts 4 times by default. So a Go writer fails on the first conflict is the surprising behavior from their point of view, not the other way around. In practice the confusion shows up like this: - Code ported from Java/PyIceberg works in testing and then fails under concurrent writes in production, with nothing in the code pointing at retries. - In a mixed Java/Go deployment, the same table property set means different things depending on which client commits. I agree the change in latency under contention is real. But users who want fail-fast can opt in with `commit.retry.num-retries=0`, and that is easier to discover than finding out there is no retry at all. With a release note and a `!` breaking-change marker, I think the parity argument wins. -- 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]
