Date: Thu, 08 Mar 2018 10:48:52 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <21103.1520534813@sss.pgh.pa.us>
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>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE of
 partition key
To: pgsql-hackers@lists.postgresql.org,Tom Lane <tgl@sss.pgh.pa.us>,Robert
 Haas <robertmhaas@gmail.com>
CC: 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>
From: Andres Freund <andres@anarazel.de>
Message-ID: <44DBC47E-36ED-4754-88EB-EBFC3FD8B45C@anarazel.de>
Precedence: bulk


On March 8, 2018 10:46:53 AM PST, Tom Lane <tgl@sss=2Epgh=2Epa=2Eus> wrote=
:
>Robert Haas <robertmhaas@gmail=2Ecom> writes:
>> On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane <tgl@sss=2Epgh=2Epa=2Eus> wro=
te:
>>> FWIW, I would also vote for (1), especially if the only way to do
>(2)
>>> is stuff as outright scary as this=2E  I would far rather have (3)
>than
>>> this, because IMO, what we are looking at right now is going to make
>>> the fallout from multixacts look like a pleasant day at the beach=2E
>
>> Whoa=2E  Well, that would clearly be bad, but I don't understand why
>you
>> find this so scary=2E  Can you explain further?
>
>Possibly I'm crying wolf; it's hard to be sure=2E  But I recall that
>nobody
>was particularly afraid of multixacts when that went in, and look at
>all
>the trouble we've had with that=2E  Breaking fundamental invariants like
>"ctid points to this tuple or its update successor" is going to cause
>trouble=2E  There's a lot of code that knows that; more than knows the
>details of what's in xmax, I believe=2E
>
>I would've been happier about expending an infomask bit towards this
>purpose=2E  Just eyeing what we've got, I can't help noticing that
>HEAP_MOVED_OFF/HEAP_MOVED_IN couldn't possibly be set in any tuple
>in a partitioned table=2E  Perhaps making these tests depend on
>partitioned-ness would be unworkably messy, but it's worth thinking
>about=2E

We're pretty much doing so for speculative lock IDs/upsert already=2E Whic=
h doesn't seem to have caused a lot of problems=2E

Andres=20
--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E