I don't see a problem with "wrapping around" - the row's xmin does not change with freeze (AFAIK). It changes when the row is modified.

So event if you hold some entity (with current xmin) for a long time (enough for "wrap around") and then try to update it, it will update ok.

"Multiple statements" possible problems is managed for us by NpgSQL :)

--
С уважением, Павел

11.08.2020, 21:39, "Andres Freund" <andres@anarazel.de>:

Hi,

On 2020-08-11 21:31:52 +0300, Pavel Biryukov wrote:
Entity Framework is an ORM for .Net (and .Net Core). It has different providers
for different databases (NpgSql for Postgres). It uses Optimistic concurrency.
The common use case is to use xmin as "concurrency token".

In code we make "var e = new Entity();", "dbContext.Add(e)" and
"dbContext.SaveChanges()" (smth like that), and EF Core constructs sql for us,
classical ORM;

When new row is inserted, EF makes an insert with "RETURNING xmin" to keep it
as concurrency token for further updates (update is made like "where id = [id]
AND xmin=[xmin]" to be sure the row hasn't been updated by other clients).

That's not really a safe use of xmin, e.g. it could have wrapped around
leading you to not notice a concurrent modification. Nor does it
properly deal with multiple statements within a transaction. Perhaps
those are low enough risk for you, but I don't xmin is a decent building
block for this kind of thing.

Greetings,

Andres Freund