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 1s83TD-009JPu-U0 for pgsql-hackers@arkaria.postgresql.org; Fri, 17 May 2024 19:42:25 +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 1s83TD-00Gwuy-W7 for pgsql-hackers@arkaria.postgresql.org; Fri, 17 May 2024 19:42:23 +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 1s83TD-00Gwtu-M0 for pgsql-hackers@lists.postgresql.org; Fri, 17 May 2024 19:42:23 +0000 Received: from mail-oo1-xc2e.google.com ([2607:f8b0:4864:20::c2e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s83T9-000lKL-9a for pgsql-hackers@lists.postgresql.org; Fri, 17 May 2024 19:42:22 +0000 Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-5b2e942171cso328932eaf.3 for ; Fri, 17 May 2024 12:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1715974937; x=1716579737; darn=lists.postgresql.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ovsH3R2DxvYbkGpHlLjWFwTqXtNQtr2h1xzrt1Joo/c=; b=fXusdCs2/uNxuNw3nx1z0/XfglYJN+zh1aQ2yyF1eNp0WB2I2k52HTZwI/O0dYqZ4g vZtJrlOOERysum9ZApMDL45cIFDi7aie0L1tIVFtpZ/OVzw4rRKIQiuW+B6n6LtEqSg1 9/pprSL4UlmXySzjKBvkBrRTesWB1NwLst2sHnEpWjtzd591HnG5BRm4I/HYYYR7AFD6 TOW1lDuwNGCwvb7mcTFehHDUKX2Dnni71MyfoMSaPRSrfnZmQigwjlmmHex83GJDgcW3 xE67dNitX5DhCMEVDJbCLZoiocMh7bx3lEXz1mzeXEIm1M9Fz3Cqna7oEj0W/Rtvc6F4 32sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715974937; x=1716579737; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ovsH3R2DxvYbkGpHlLjWFwTqXtNQtr2h1xzrt1Joo/c=; b=fBTC+x+rMoa0pThTJij+dqFJHWPInu6Sdk5gOoX+yAUy+auYt7YAxbrUH04x8ege1R hkRUrG0nDFT7WwdMd/xOf/Se7GiJvXABu3lp/peVv7XCJJbmFDf26phhT+pBurPCkXIL Dwfum5X16ySFQx9IPKYDE/QipGeaHicRuBbBg2RWGDjY8lki/V0HZdUoxvTosaS7Bwcp dpdfBepdWNlyFcnJIMCj4yKpV2effxXqUdvfAHUg5yywery9akJj1bzs1WGPZ2LRvyfO 6FTxW566/o7dl+kqYo+sEN/zUHzH5CXlZdpLSp02REiIInnRtWoIWt7OKZQemvHqRXPm +WnQ== X-Forwarded-Encrypted: i=1; AJvYcCW7b+i2ZnJk2gZStyqpdAOQixoMxCXsfo/97Q24muynhktlv+vN+yqOzO0Xc+idYduRH4KWlZTxgiWFStgF1UPxsdFQE8dq4p1CoOb2Ae9cHhKU X-Gm-Message-State: AOJu0YxnJyM0Yg1PSFpyalUAprg6pEo27GWBIwR1+xwgvnogMyHKATNY H76g2CXbtkuzjJ8vtfcDxdwQkR1bfxurecEiKiAi40BamrTy8jMBCNF0APa2WQ== X-Google-Smtp-Source: AGHT+IFYK/yebYm1Y4yia1QYB4nTXnjb4l4PkiTlW/ecmVoUBAm955t+XrJXy4wZ/2KtqlUDWVTWqg== X-Received: by 2002:a05:6358:e486:b0:186:41a2:cbd2 with SMTP id e5c5f4694b2df-193bd0001d8mr2266048555d.27.1715974937534; Fri, 17 May 2024 12:42:17 -0700 (PDT) Received: from smtpclient.apple (24-113-197-127.wavecable.com. [24.113.197.127]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-634105e0762sm15331860a12.63.2024.05.17.12.42.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 May 2024 12:42:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\)) Subject: Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index. From: Mark Dilger In-Reply-To: <28FCD9E5-795E-44F4-ADFA-DBCAC1945DA1@enterprisedb.com> Date: Fri, 17 May 2024 12:42:26 -0700 Cc: Alexander Korotkov , Tom Lane , Noah Misch , Peter Eisentraut , Aleksander Alekseev , Postgres hackers , Maxim Orlov , Andres Freund , Greg Stark , Julien Rouhaud , David Steele , Peter Geoghegan , Maxim Orlov , lubennikovaav@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: <65DAA5C7-457C-4BF8-ACAF-43E931A67BA0@enterprisedb.com> References: <20220922151328.lakwdytvwnyyif3b@awork3.anarazel.de> <8c74cc5e-4b97-4cd7-9aaf-67886822a78c@eisentraut.org> <20240501022412.85@rfd.leadboat.com> <1375614.1715301775@sss.pgh.pa.us> <8635D8B1-45B7-4D67-86C7-D6ECB4F10B11@enterprisedb.com> <2EDAC2EB-E8C2-4B56-9094-288ABD45DA4E@enterprisedb.com> <28FCD9E5-795E-44F4-ADFA-DBCAC1945DA1@enterprisedb.com> To: Pavel Borisov X-Mailer: Apple Mail (2.3731.700.6.1.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On May 17, 2024, at 12:10 PM, Mark Dilger = wrote: >=20 >> Amcheck with checkunique option does check uniqueness violation = between pages. But it doesn't warranty detection of cross page = uniqueness violations in extremely rare cases when the first equal index = entry on the next page corresponds to tuple that is not visible (e.g. = dead). In this, I followed the Peter's notion [1] that checking across a = number of dead equal entries that could theoretically span even across = many pages is an unneeded code complication and amcheck is not a tool = that provides any warranty when checking an index. >=20 > This confuses me a bit. The regression test creates a table and index = but never performs any DELETE nor any UPDATE operations, so none of the = index entries should be dead. If I am understanding you correct, I'd be = forced to conclude that the uniqueness checking code is broken. Can you = take a look? On further review, the test was not anticipating the error message "high = key invariant violated for index". That wasn't seen in calls to = bt_index_parent_check(), but appears as one of the errors from = bt_index_check(). I am rerunning the test now.... =E2=80=94 Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company