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 1ryn4c-000Usm-Rq for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Apr 2024 06:22:42 +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 1ryn4b-0009OX-Eb for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Apr 2024 06:22:41 +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 1ryn4b-0009ON-5f for pgsql-hackers@lists.postgresql.org; Mon, 22 Apr 2024 06:22:41 +0000 Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ryn4Y-002Hxe-Hb for pgsql-hackers@postgresql.org; Mon, 22 Apr 2024 06:22:40 +0000 Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-de4640ec49fso4196611276.2 for ; Sun, 21 Apr 2024 23:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713766957; x=1714371757; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j6mH+obBJB4LsJIEKRYfXg9UrSY2wQ0i2x9lPP5gVYY=; b=VS+uKX5j7Bk6mHltKbTpmUELqZosIFoQ741qi+wxYlzXi7z2iMHOj6Qwem10zgKhgf q/rnchA7/rq8s5RmdhPqom2NbVJ3N7qYHmxU/juKBDpwdrfkZa+ZU8qf/gHVPUPeNxPn 3GquaJp1Lwm7It2gy/GK39ZtK1bA7een8P9S+o0VwMa5bouvdLOJSS9+h2sV6yRD7H7g EykC2j5DvCJoPVb965gDUDWa9qbenRO775DBFqwfUdx8iDjXU6CFOBILzVeVkkBTzm0M SCZgHYObKz153TA30t9y9qzfjUOmJeKkhea7mzTONPRQxmozWhLbwrj3JRs4YI4iER7g jx7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713766957; x=1714371757; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j6mH+obBJB4LsJIEKRYfXg9UrSY2wQ0i2x9lPP5gVYY=; b=OIynNeTI5ZtZ3HdwJZfzOyZ2SbleIoOQf1saDcASMPQRacyCfeP/M3woUxKTYGlp9i GA5HtzFjAu1KnFAV7H/5UgtW+BWsLg4rLIcKarIpMc9Zkgz4F7jhYAWuUbJWOVYro3Dx /C3KkdlKLXvhjxX4VRB2+48bAAKEXE2vqJnp4Ks7r7tc0DVpXNrqYuPKe4v0pHLoqoUO +0cNH48lD3fCzyhyMCvEi987R6LCQycShnngnPlZTUcap7bOe/cmBNjYWIta0eNtkQ0f ukDZcD16cUfGQ96KblcDbUuD+z6hYJUZksdXTsuAVft0ctRBOSV/4CYf5CFljdZbEhr3 zvqA== X-Gm-Message-State: AOJu0YziL/w9gUkXVEXLumswnruYlMNyEYqF2j6Ricajycq4vNMn5nsA PSWn9PR1XJt/dYQRMIdjErVM/zYZ6jyP6UGDrSyQdhfY9uGW6NSkpiPQ6XBtiD0kMV/G2tpk7Tb szK9JV9Qmbd9Iuy2I2UU7rIHCqRmn9Hw1Fm4= X-Google-Smtp-Source: AGHT+IFT8UtQQqXIAHzeYxnI9yZsBU5zUXUX8VsuksskYWLpmT76CsIAhXBZ3QuQfIV/d9UNIlBfVOQpb+LbHmYnqZQ= X-Received: by 2002:a25:d803:0:b0:dc6:dc58:8785 with SMTP id p3-20020a25d803000000b00dc6dc588785mr8645577ybg.62.1713766956774; Sun, 21 Apr 2024 23:22:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Guo Date: Mon, 22 Apr 2024 14:22:25 +0800 Message-ID: Subject: Re: Assert failure in _bt_preprocess_array_keys To: Peter Geoghegan Cc: PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000afbee90616a9768f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000afbee90616a9768f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 22, 2024 at 10:52=E2=80=AFAM Peter Geoghegan wrote= : > On Sun, Apr 21, 2024 at 10:36=E2=80=AFPM Richard Guo > wrote: > > I didn't spend much time digging into it, but I wonder if this Assert i= s > > sensible. I noticed that before commit 5bf748b86b, the two datatypes > > were not equal to each other either (anyrange vs. int4range). > > The assertion is wrong. It is testing behavior that's much older than > commit 5bf748b86b, though. We can just get rid of it, since all of the > information that we'll actually apply when preprocessing scan keys > comes from the operator class. > > Pushed a fix removing the assertion just now. Thanks for the report. That's so quick. Thank you for the prompt fix. Thanks Richard --000000000000afbee90616a9768f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Apr 22, 2024 at 10:52=E2=80=AFAM = Peter Geoghegan <pg@bowt.ie> wrote:=
On Sun, Apr 21,= 2024 at 10:36=E2=80=AFPM Richard Guo <guofenglinux@gmail.com> wrote:
> I didn't spend much time digging into it, but I wonder if this Ass= ert is
> sensible.=C2=A0 I noticed that before commit 5bf748b86b, the two datat= ypes
> were not equal to each other either (anyrange vs. int4range).

The assertion is wrong. It is testing behavior that's much older than commit 5bf748b86b, though. We can just get rid of it, since all of the
information that we'll actually apply when preprocessing scan keys
comes from the operator class.

Pushed a fix removing the assertion just now. Thanks for the report.

That's so quick.=C2=A0 Thank you for the prom= pt fix.

Thanks
Richard
--000000000000afbee90616a9768f--