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 don't think this is that big a problem. All code already needs to handle 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 == new.xmin checks. Which will, without any changes, catch the proposed scheme, no?

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