Hi Jagdeep,
Thanks for the proposal! I agree with Drew’s second point emphasis on clarifying the goals for snapshot and serializable isolation guarantees before committing to catalog changes. Note a lot of the following rationale is also from this Github PR <https://github.com/apache/iceberg/pull/6948/files#r1244026460>a while back which I think summarizes the crux of the issue pretty well. The current proposal advocates for strict multi-table snapshot isolation, treating the catalog as the authority for transactional point-in-time consistency. While this approach may end up being necessary, I suggest we first formalize what “snapshot isolation” and “serializable” concretely mean in Iceberg’s context. For example, Snapshot Isolation: Prevent dirty/non-repeatable reads, lost updates, and phantom reads across tables. Serializable: Add prevention of write skew to the SI definition. The phantom read example in the proposal’s "Limitation 1" illustrates a clear anomaly that snapshot isolation must prevent. However, the proposal assumes the catalog must enforce point-in-time consistency in order for Iceberg to support multi-statement/table transactions. Point in time across entities in catalog is made difficult by the fact that there isn't a causal ordering between commits across tables, but multi-table transactions can inherently have this, so catalogs themselves may not even be reliable for such a notion. See https://github.com/apache/iceberg/pull/6948/files#r1251319541 <https://github.com/apache/iceberg/pull/6948/files#r1251319541> Clients may not need an authoritative point in time view to ensure an isolation guarantee so long as the overall outcome of the transaction aligns with isolation guarantees. So long as the client can guarantee through existing mechanisms that the outcome of any operation is correct as per the isolation level (i.e. verifying no read data in the transaction has been modified) there may not be a need for catalogs to keep track of all that state. This moves the snapshot isolation definition closer to serializable isolation, but I think that's fine since levels can always be stricter and then we relax the use cases which we know we should support for snapshot isolation but not serializable. To be convinced that catalog changes are required, I think I'd need to see more examples for where it's either really complicated on the client to do that validation, not scalable on the client (I'm skeptical users are really doing multi table/statement transactions over many tables, but I can be wrong), or it's somehow insufficient from a correctness perspective considering the previously mentioned alternative of client side doing a more "serializable isolation" like validation. Let me know if I'm missing something! Thanks, Amogh Jahagirdar
