> This problem could be easily solved by assigning in step 2 timestamp
> when update becomes visible for other transactions (transaction commit
> timestamp in other words) instead of CURRENT_TIMESTAMP or
> clock_timestamp().

This is logically impossible. Postgres has to write new row versions *before* it can finally commit to make them visible. It would require prophetic capabilities to write a timestamp that's not determined yet at the time of writing.

You can get *commit timestamps* from a different source: since Postgres 9.5, there is a GUC setting **`track_commit_timestamp`** which instruct Postgres to starts logging commit timestamps globally.

Then you can get commit timestamps with the utility function [`pg_xact_commit_timestamp(xid)`][1]. Your query could look like:

 SELECT * FROM my_table t
 WHERE pg_xact_commit_timestamp(t.xmin) > _some_persisted_timestamp;

See:

- https://dba.stackexchange.com/questions/159189/how-do-i-write-a-postgres-sql-command-based-on-metadata-of-the-tables-themselves/159221#159221

But I am not completely sure I understand your task. Maybe you need a queuing tool or process rows one by one like discussed here:

- https://dba.stackexchange.com/questions/69471/postgres-update-limit-1/69497#69497

 [1]: https://www.postgresql.org/docs/current/functions-info.html#FUNCTIONS-COMMIT-TIMESTAMP