Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6oCe-0005aA-Tp for pgsql-committers@arkaria.postgresql.org; Thu, 21 Mar 2019 03:17:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h6oCd-0007l4-Bc for pgsql-committers@arkaria.postgresql.org; Thu, 21 Mar 2019 03:17:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6oCd-0007gp-2P for pgsql-committers@lists.postgresql.org; Thu, 21 Mar 2019 03:17:11 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6oCa-0000W5-KB for pgsql-committers@lists.postgresql.org; Thu, 21 Mar 2019 03:17:09 +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 x2L3H4xd021984; Wed, 20 Mar 2019 23:17:04 -0400 From: Tom Lane To: Peter Geoghegan cc: pgsql-committers Subject: Re: pgsql: Make heap TID a tiebreaker nbtree index column. In-reply-to: References: <13999.1553105283@sss.pgh.pa.us> <24277.1553114810@sss.pgh.pa.us> <16667.1553116435@sss.pgh.pa.us> <17604.1553118255@sss.pgh.pa.us> <17845.1553118645@sss.pgh.pa.us> <8748.1553119737@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Wed, 20 Mar 2019 16:39:20 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21982.1553138224.1@sss.pgh.pa.us> Date: Wed, 20 Mar 2019 23:17:04 -0400 Message-ID: <21983.1553138224@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Geoghegan writes: > On Wed, Mar 20, 2019 at 3:11 PM Peter Geoghegan wrote: >> On Wed, Mar 20, 2019 at 3:08 PM Tom Lane wrote: >>> And done. Should be possible to revert 7d3bf73ac, if you wish. > Actually, I'm not sure why it would be fine to revert 7d3bf73ac now. > Might the problem actually be the order in which OIDs are originally > assigned, or something like that? No, because then things would have been unstable before, no? I actually think that we should remove most or all of the cascade-drop-hiding hacks that are in the regression tests now, not only that one. They should not be necessary any more, and they might be hiding things we need to know about, now or in the future. But I haven't got round to it. regards, tom lane