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

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.

regards, tom lane