Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qqPuQ-009zFS-Dj for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Oct 2023 03:29:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qqPuN-00CBOa-UO for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Oct 2023 03:29:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qqPuN-00CBNM-Bg for pgsql-hackers@lists.postgresql.org; Wed, 11 Oct 2023 03:29:16 +0000 Received: from mail-yb1-xb36.google.com ([2607:f8b0:4864:20::b36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qqPuL-001OXw-1V for pgsql-hackers@postgresql.org; Wed, 11 Oct 2023 03:29:15 +0000 Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-d8afe543712so6873034276.0 for ; Tue, 10 Oct 2023 20:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1696994951; x=1697599751; darn=postgresql.org; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=89YV6D3rDdXuXFmwhxQ6NzCFlqKacMDsIONaRGl0q60=; b=atoWbJcxgNMS1EK24OCrLUxq/h7fp0odZYEwB087j3ZKt+CYlOIVaLCdS6rrniYfMw //eQAuNIxRTgn0EwZ/ivbjlUygKyjzFxVYEuNHi3LubEyn5TmLMXR8cdUoON7bhWvhTa 2ZuJQ9CbL46MVy4VJAQJz8o1L3iupjG4uXM5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696994951; x=1697599751; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=89YV6D3rDdXuXFmwhxQ6NzCFlqKacMDsIONaRGl0q60=; b=WKjDX2T9mP/mw8bkfitIeEK6FvpgdkQAyAnPkasgkoFdmwXt+8CXodDW1zzskt+lYE UR8IQC4it8/aVzNMxrpQV8H+Mx45wj2y1eOPR1xFcOKI9fBaiYLCWvI7iwOhThhSA50c AkGyfThlp9ohMPkxJifjzhvNyIb/Zw0Qe+fWgqZ1G2JPL8Gbw/PCFb4HzZLJIxeV5yYf gu6Eu6PSXZmQWtE3P6C1Sv7fRRFGnnfTF5Y7dViHsbk4L8YcPaseuOMp6dgWYx5z+00C Rhj2B1XVB5CoCw5+kd8Jnfatj4IdSV7aC2rsjHNoHT9Cpy5tZHw9jY16eLdyxVzKbszG rDYA== X-Gm-Message-State: AOJu0YwcRMZ+z8mxU+LxvW8v9rJhKP+RXGjTDXGPu+u7oSHZ1ThfLoJc In+YGdnkmrU3pxUII84XMUDkhRseMWzMfXBlsEo= X-Google-Smtp-Source: AGHT+IG5SUF2Z6KOy6H5rgJ6ta0oam9n+lTfpiyQsvR0zaXkc4lFW0YVaYHQj36iN4J5E7ZBaTbDsw== X-Received: by 2002:a05:6902:50e:b0:d81:69f7:1731 with SMTP id x14-20020a056902050e00b00d8169f71731mr18664905ybs.18.1696994950975; Tue, 10 Oct 2023 20:29:10 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id r2-20020a5b06c2000000b00d7f06aa25c5sm4160321ybq.58.2023.10.10.20.29.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Oct 2023 20:29:10 -0700 (PDT) Date: Tue, 10 Oct 2023 20:29:08 -0700 From: Noah Misch To: Peter Geoghegan Cc: pgsql-hackers@postgresql.org Subject: Re: interval_ops shall stop using btequalimage (deduplication) Message-ID: <20231011032908.35@rfd.leadboat.com> References: <20231011013317.22.nmisch@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Oct 10, 2023 at 08:12:36PM -0700, Peter Geoghegan wrote: > On Tue, Oct 10, 2023 at 6:33 PM Noah Misch wrote: > > interval_ops, however, recognizes equal-but-distinguishable values: > > > Fails with: > > > > 2498151 2023-10-10 05:06:46.177 GMT DEBUG: building index "ti" on table "t" serially > > 2498151 2023-10-10 05:06:46.178 GMT DEBUG: index "ti" can safely use deduplication > > TRAP: failed Assert("!itup_key->allequalimage || keepnatts == _bt_keep_natts_fast(rel, lastleft, firstright)"), File: "nbtutils.c", Line: 2443, PID: 2498151 > > Nice catch. > > Out of curiosity, how did you figure this out? Did it just occur to > you that interval_ops had a behavior that made deduplication unsafe? > Or did the problem come to your attention after running amcheck on a > customer database? Or was it something else? My friend got an amcheck "lacks matching index tuple" failure, and they asked me about it. I ran into the assertion failure while reproducing things. > I'm a little surprised that it took this long to notice > the interval_ops issue. Agreed. I don't usually store interval values in tables, and I'm not sure I've ever indexed one. Who knows. > Do we really need to change the catalog contents when backpatching? Not really. I think we usually do. On the other hand, unlike some past cases, there's no functional need for the catalog changes. The catalog changes just get a bit of efficiency. No strong preference here.