IssueTracker

Per documentation the following restrictions apply to the use of the PENDING_COMMIT_TIMESTAMP function,

After you call the PENDING_COMMIT_TIMESTAMP function, the table and any derived index is unreadable to any future SQL statements in the transaction. [...] If you try to read the table, then Spanner produces an error.

Some notable use cases affected by these restrictions include,

• Conditional updates based on commit timestamp. When making conditional updates to multiple rows based on timestamp, the first successful update can prohibit subsequent updates in the same transaction (e.g. UPDATE t SET updated_at = PENDING_COMMMIT_TIMESTAMP(), ... WHERE updated_at = @last_updated AND ...).
• Multiple DML inserts/updates on an indexed commit timestamp columns. While not explicitly stated in documentation, writing a PENDING_COMMIT_TIMESTAMP() value to an indexed column with DML will prohibit subsequent writes to the same column.
• Reading unrelated rows after using PENDING_COMMIT_TIMESTAMP(). Attempting to read a table after a PENDING_COMMIT_TIMESTAMP() has been written may be prohibited, even when the rows read do not themselves contain the pending commit timestamp values. For this reason, the documentation linked above recommends performing all commit timestamp writes at the end of a transaction.

Thus, the feature request here is to reduce these restrictions to permit more use cases involving commit timestamps, particularly those use cases without straightforward work arounds.