Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eu0ZA-0003Ca-Ov for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Mar 2018 18:47:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1eu0Z9-0006cw-KY for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Mar 2018 18:46:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eu0Z9-0006cm-DN for pgsql-hackers@lists.postgresql.org; Thu, 08 Mar 2018 18:46:59 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eu0Z6-0005je-04 for pgsql-hackers@postgresql.org; Thu, 08 Mar 2018 18:46:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w28IkrLp021104; Thu, 8 Mar 2018 13:46:53 -0500 From: Tom Lane To: Robert Haas cc: Pavan Deolasee , amul sul , Amit Kapila , Stephen Frost , PostgreSQL-development Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key In-reply-to: References: <20180111143641.GJ2416@tamriel.snowman.net> <10896.1520521635@sss.pgh.pa.us> <8293.1520528639@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Thu, 08 Mar 2018 12:07:31 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21102.1520534813.1@sss.pgh.pa.us> Date: Thu, 08 Mar 2018 13:46:53 -0500 Message-ID: <21103.1520534813@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane 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