stevenzwu commented on code in PR #16294:
URL: https://github.com/apache/iceberg/pull/16294#discussion_r3228610211
##########
format/spec.md:
##########
@@ -751,6 +751,8 @@ A snapshot consists of the following fields:
| | | _required_ | **`added-rows`** |
The upper bound of the number of rows with assigned row IDs, see [Row
Lineage](#row-lineage) |
| | | _optional_ | **`key-id`** | ID
of the encryption key that encrypts the manifest list key metadata |
+In format version 4 and above, a snapshot's `timestamp-ms` must be strictly
greater than the `timestamp-ms` of its parent snapshot on the same branch. Root
snapshots (those without a parent) are not constrained by this requirement.
Review Comment:
Good catch. Pushed an update that explicitly carves out pre-upgrade
snapshots:
> In format version 4 and above, a snapshot's `timestamp-ms` must be
strictly greater than the `timestamp-ms` of its parent snapshot on the same
branch. The requirement applies only to snapshots committed while the table is
at format version 4 or higher; root snapshots, and snapshots that existed
before a table was upgraded to v4, are not constrained.
So a table migrated from v3 with non-monotonic timestamps is conformant: the
existing snapshots are grandfathered in, and only new snapshots committed at
v4+ must satisfy the rule. A new v4 snapshot whose parent happens to be a
pre-upgrade snapshot must still beat that parent's `timestamp-ms`, which will
naturally fast-forward past any anomaly inherited from v3.
--
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]
