From: Pavel Biryukov <79166341370@yandex.ru>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: posgres 12 bug (partitioned table)
Date: Tue, 11 Aug 2020 21:55:32 +0300
Message-ID: <844551597171844@mail.yandex.ru> (raw)
In-Reply-To: <20200811183940.z6hvnu4uptkhugom@alap3.anarazel.de>
References: <141051591267657@mail.yandex.ru>
<1251598.1591289850@sss.pgh.pa.us>
<CA+TgmoaN0kQa3nxToHtD8nRymSnUYaj4XL3zKq8Q_0AUJcQNPQ@mail.gmail.com>
<3398357.1597160032@sss.pgh.pa.us>
<1058041597161586@mail.yandex.ru>
<20200811172241.izeyvksgevbtvhcd@alap3.anarazel.de>
<24981597170121@mail.yandex.ru>
<20200811183940.z6hvnu4uptkhugom@alap3.anarazel.de>
<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@anarazel.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>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: 79166341370@yandex.ru, andres@anarazel.de, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: posgres 12 bug (partitioned table)
In-Reply-To: <844551597171844@mail.yandex.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox