Option to ensure monotonic timestamps

Hi, I'm new to Postgres hacking, and I'm interested in the possibility of a new feature to make it possible to ensure that Postgres-generated timestamps never decrease even if the system clock may step backwards. My use case is that I'm implementing a form of temporal tables based on transaction commit timestamps (as returned by pg_xact_commit_timestamp), and to ensure the integrity of the system I need to know that the ordering of the commit timestamps will always be consistent with the order in which the transactions actually committed. I don't need the timestamps to be unique; i.e., if transactions occur close together in time, then it's fine for them to have the same timestamp -- just if the timestamps are different then they must be in the right order. I would guess there may be other scenarios where users may want to ensure the timestamps are monotonic, and in general it would probably be desired for the monotonicity to apply across all timestamps generated by a given Postgres server, not only the commit timestamps.

I'm aware of the obvious alternative, which is simply to try to configure the system clock so that it can't go backwards (e.g., using the option "stepback 0" for ntpd). However, in virtual environments this could potentially be difficult to achieve in a reliable way. And in any case, since in my application the integrity of the data history hinges on the timestamps being monotonic, I think it makes sense that this be enforceable on the database level.

What I propose is that we could add a boolean configuration option, say 'ensure_monotonic_timestamps', that enables the following behavior: when GetCurrentTimestamp is called (https://doxygen.postgresql.org/backend_2utils_2adt_2timestamp_8c.html#a9822cdf3fd41b15851c0c18ddc80143c), before it returns it checks if `result` is less than what was returned last time (if any) that GetCurrentTimestamp was called, and if so it returns the result from the previous call (after logging a warning), otherwise it proceeds as normal. In its simplest form, this could be accomplished by adding a global variable lastGetCurrentTimestamp that stores the result of the previous call. Since GetCurrentTimestamp appears to be the source of all of the significant system-generated timestamps, including commit timestamps, this should produce the behavior I'm looking for. 

One tricky thing is to figure out how to make this reliable even in the situation where the database engine has to be restarted. When we're starting up and have to initialize lastGetCurrentTimestamp, we need to make sure to make sure we initialize it to be at least as large as the largest previous result of GetCurrentTimestamp that made its way into the WAL before shutdown, i.e., the largest previous result of GetCurrentTimestamp that has the potential to be written out to tables upon recovery. What's fuzzy to me is whether this would require writing new data to the WAL specifically for this, or whether there are already timestamps (e.g., as part of WAL metadata) that could serve this purpose.

Any thoughts?

- Brent Kerby