<div> </div><div>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.</div><div>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.</div><div> </div><div>"Multiple statements" possible problems is managed for us by NpgSQL :)</div><div> </div><div>-- <br />С уважением, Павел</div><div> </div><div> </div><div> </div><div>11.08.2020, 21:39, "Andres Freund" <andres(at)anarazel(dot)de>:</div><blockquote><p>Hi,<br /><br />On 2020-08-11 21:31:52 +0300, Pavel Biryukov wrote:</p><blockquote> Entity Framework is an ORM for .Net (and .Net Core). It has different providers<br /> for different databases (NpgSql for Postgres). It uses Optimistic concurrency.<br /> The common use case is to use xmin as "concurrency token".<br /> <br /> In code we make "var e = new Entity();", "dbContext.Add(e)" and<br /> "dbContext.SaveChanges()" (smth like that), and EF Core constructs sql for us,<br /> classical ORM;<br /> <br /> When new row is inserted, EF makes an insert with "RETURNING xmin" to keep it<br /> as concurrency token for further updates (update is made like "where id = [id]<br /> AND xmin=[xmin]" to be sure the row hasn't been updated by other clients).</blockquote><p><br />That's not really a safe use of xmin, e.g. it could have wrapped around<br />leading you to not notice a concurrent modification. Nor does it<br />properly deal with multiple statements within a transaction. Perhaps<br />those are low enough risk for you, but I don't xmin is a decent building<br />block for this kind of thing.<br /><br />Greetings,<br /><br />Andres Freund</p></blockquote>