Postgres sequences can commit out-of-order

This details an approach to working with commit-ordered event IDs which is a very powerful primitive to, e.g., do pub/sub event processing within a SQL database without having to deal with outbox patterns, event brokers and so on.

People throw Kafka or Event Hub at everything, but really, if you do not need to offload your DB for storage/access of massive amounts of events, you may not need them...

I have a lot of experience with this approach on MS SQL (https://github.com/vippsas/mssql-changefeed), interesting to see the same thing on postgres.

Hope databases gets these things built in (i.e., supported more directly) in the future.

I wonder if this is a bug:

   -- If no locks are found, return the maximum possible bigint value
    if max_seq is null then
        return 9223372036854775807;
    end if;

Would be a race here by returning a big number to the caller, then more data is written in between? Should instead check the current max sequence number before checking the locks?