That's interesting, although "read committed" here would be different from the isolation level of the same name. It seems really tricky to implement since tuples could be removed during a query. E.g. the backend could fail to chase tuple-id pointers, and there would be cases where it can be difficult to ensure a tuple is returned exactly once for a given scan.

If you use ordinary READ COMMITTED transactions, they will advance their xmin horizons on each query (and allow old version cleanups) up until their own transaction id but unfortunately not beyond that. For a given table, this is important since that transaction is uncommitted and it might modify the table. If you could make long-running transactions readonly on those specific tables, then you could use a different xmin horizon specifically for those tables. It would require a lot of duplicative bookkeeping in shared memory though. You could probably fake this today by using 2 databases on the same machine and using two-phase-commit+dblink/fdw for cross-database transactions/queries (fdw uses repeatable read in transactions, so it won't allow the xmin to advance).

Surely the last place you'd want to use those weaker consistency guarantees is a concurrency limiter?