←back to thread

Postgres UUIDv7 and per-back end monotonicity

(brandur.org)
230 points craigkerstiens | 1 comments | 02 Jan 25 16:32 UTC | HN request time: 0.221s | source
Show context
mmerickel ◴[02 Jan 25 18:02 UTC] No.42576848[source]▶
Remember even if timestamps may be generated using a monotonically increasing value that does not mean they were committed in the same order to the database. It is an entirely separate problem if you are trying to actually determine what rows are "new" versus "previously seen" for things like cursor-based APIs and background job processing. This problem exists even with things like a serial/autoincrement primary key.
replies(1): >>42577477 #
1. shalabhc ◴[02 Jan 25 18:56 UTC] No.42577477[source]▶
+1

What could be useful here is if postgres provided a way to determine the latest frozen uuid. This could be a few ms behind the last committed uuid but should guarantee that no new rows will land before the frozen uuid. Then we can use a single cursor track previously seen.