> 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 writes new row versions *before* it finally commits to make them visible. It would require prophetic capabilities to write a future timestamp yet unknown at the time of writing.

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

Then you can get commit timestamps with the utility function [`pg_xact_commit_timestamp(xid)`][2]. 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
- https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.5#Commit_timestamp_tracking

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]: http://www.postgresql.org/docs/current/static/runtime-config-replication.html#GUC-TRACK-COMMIT-TIMESTAMP
 [2]: https://www.postgresql.org/docs/current/functions-info.html#FUNCTIONS-COMMIT-TIMESTAMP