Many database applications need accountability
and trace-ability that necessitate retaining previous
database states. For a transaction-time database supporting
this, the choice of times used to timestamp
database records, to establish when records are or were
current, needs to be consistent with a committed transaction
serialization order. Previous solutions have chosen
timestamps at commit time, selecting a time that
agrees with commit order. However, SQL standard
databases can require an earlier choice because a statement
within a transaction may request “current time.”
Managing timestamps chosen before a serialization order
is established is the challenging problem we solve

By building on two-phase locking concurrency control,
we can delay a transaction’s choice of a timestamp,
reducing the chance that transactions may need
to be aborted in order keep timestamps consistent with
a serialization order. Also, while timestamps stored
with records in a transaction-time database make it
possible to directly identify write-write and write-read
conflicts, handling read-write conflicts requires more.
Our simple auxiliary structure conservatively detects
read-write conflicts, and hence provides transaction
timestamps that are consistent with a serialization order.