From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>,
        Pavan Deolasee <pavan.deolasee@gmail.com>,
        amul sul <sulamul@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>,
        Stephen Frost <sfrost@snowman.net>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE of
 partition key
In-reply-to: <DB971D6C-0C1D-4F2F-B08A-D4A1EBD844E5@anarazel.de>
References: 
 <CAAJ_b95PkwojoYfz0bzXU8OokcTVGzN6vYGCNVUukeUDrnF3dw@mail.gmail.com>
 <20180111143641.GJ2416@tamriel.snowman.net>
 <CAAJ_b96UMma8VUMtvqDzEWUFObfbNXAc-9c4GvAQ2kSwCKURww@mail.gmail.com>
 <CAA4eK1LHVnNWYF53F1gUGx6CTxuvznozvU-Lr-dfE=Qeu1gEcg@mail.gmail.com>
 <CAAJ_b95R4i-+4VevSYEg1HdT+Zq6v5BuZ1zD14-yzpxe+kioqg@mail.gmail.com>
 <CAA4eK1LrOf+ZGkjMbiL7GjvFXoQ_O+XPyXHTL-L5yhd+WU4NWQ@mail.gmail.com>
 <CAAJ_b97w_GGV-k4ErxWTpz5sAgFJ4aUYMx0khfySvANmWRzsag@mail.gmail.com>
 <CAA4eK1Kn7EgUdnFnp0d+Jk7Chf88qsyzNBDfJ8OJsMGpKuX4mA@mail.gmail.com>
 <CAA4eK1KtsTqsGDggDCrz2O9Jgo7ma-Co-B! 8+v3L2zWMA2NHm6A@mail.gmail.com>
 <CAAJ_b95GpE7Qh+17zY-d5p5xPfqcTSY5ppEiYyeGTmoPaw=zXQ@mail.gmail.com>
 <CABOikdPXwqkLGgTZZm2qYwTn4L69V36rCh55fFma1fAYbon7Vg@mail.gmail.com>
 <10896.1520521635@sss.pgh.pa.us>
 <CA+Tgmob5gn1oKCjBUu8t7Go4h_AZfN5yy22N_Jv0OK8advJoWA@mail.gmail.com>
 <8293.1520528639@sss.pgh.pa.us>
 <CA+TgmoZzaH3WMhyLg_STX6=J+5iqQ0GvRWBnQihgDarF_mWSYg@mail.gmail.com>
 <21103.1520534813@sss.pgh.pa.us> <DB97!
 1D6C-0C1D-4F2F-B08A-D4A1EBD844E5@anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Thu, 08 Mar 2018 11:19:12 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23433.1520537159.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 08 Mar 2018 14:25:59 -0500
Message-ID: <23434.1520537159@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On March 8, 2018 10:46:53 AM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Breaking fundamental invariants like
>> "ctid points to this tuple or its update successor" is going to cause
>> trouble.  There's a lot of code that knows that; more than knows the
>> details of what's in xmax, I believe.

> I don't think this is that big a problem. All code already needs to hand=
le the case where ctid points to an aborted update tuple. Which might long=
 have been replaced by as an independent role. That's why we have all this=
 updated.xmax =3D=3D new.xmin checks. Which will, without any changes, cat=
ch the proposed scheme, no?

No.  In those situations, the conclusion is that the current tuple is
live, which is exactly the wrong conclusion for a cross-partition update.
Or at least it might be the wrong conclusion ... I wonder how this patch
works if the updating transaction aborted.

			regards, tom lane