Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On March 8, 2018 10:46:53 AM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> FWIW, I would also vote for (1), especially if the only way to do
>(2)
>>> is stuff as outright scary as this. 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.
>
>> Whoa. Well, that would clearly be bad, but I don't understand why
>you
>> find this so scary. Can you explain further?
>
>Possibly I'm crying wolf; it's hard to be sure. 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. 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 would've been happier about expending an infomask bit towards this
>purpose. 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. Perhaps making these tests depend on
>partitioned-ness would be unworkably messy, but it's worth thinking
>about.

We're pretty much doing so for speculative lock IDs/upsert already. Which doesn't seem to have caused a lot of problems.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.