On March 8, 2018 10:46:53 AM PST, Tom Lane <t...@sss.pgh.pa.us> wrote: >Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane <t...@sss.pgh.pa.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.
