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 1sFILL-000uk9-Oc for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Jun 2024 19:00:12 +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 1sFILJ-002w31-UA for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Jun 2024 19:00:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sFILJ-002w2t-H2 for pgsql-hackers@lists.postgresql.org; Thu, 06 Jun 2024 19:00:10 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sFILE-0002ZA-Nj for pgsql-hackers@postgresql.org; Thu, 06 Jun 2024 19:00:09 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-52b938587a4so1531825e87.1 for ; Thu, 06 Jun 2024 12:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717700403; x=1718305203; darn=postgresql.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=pGHvQGPqy7/9wHpKVJt5EkdF9XT0AtSg5G6kSdL5c2U=; b=ADWvpV7Gv9dYhYKQQx6r+MxNew4HyOzdTr7ROnnYil6lote7I9uUFgRS0ya9dO8WMW +EPrm7V43EoGAgTVZmRuLx2TY0vFacKciySXBbxcLIKqijTQqq6gHl5SNlhzDnAyJyFz ZeGsTUi7Aq85Cq5K/FZ+ODgYtY4fVAPOxDyyJ34uqNFWJks6Kp9c2brKxQ17HlEDXiI1 Wi1AAfBk06bdFpAWUUOl9iLuLZPkW/xNZUEagO7XKNLC5tR4nL2Kg9RStkskLQzk8njk AOXRERbSg3agrth5k1SiYs0QK8cp5jxGe5O6jwY0iN5Vi7mH8w3kjhC4M8bRCz6ZESAa q6Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717700403; x=1718305203; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pGHvQGPqy7/9wHpKVJt5EkdF9XT0AtSg5G6kSdL5c2U=; b=wEfTBRvHWWwG3gIaLFg7+23RVP5KE4WD/3XS+uOD6TEC0uRtInP24cS/gRUE59Kjxj HIFMC9+50WD2BOG3iLvzurtnqI/uUGKnsJyhBgmA/+SbU8JVtUhcXw1CssYMsA3v/iEF 5UaaQq0nKxPBtBHd1gIaaRQzScd5oozWgaZS10Z7/ncrW5wY7gF0g3RFz3e8dPFgdQST 0lnKKVqsw2jClkeyFmiOiGZWAR+RlMdO3cv2ezTmu5v75jUFPlYzGqGiS9Q85oKtWG7u SoKpa8sW82ppGm1AYk6sZN9H3aQkUUDAlhcSanwBnKaRsK8kxCjLXwCMV2YAlI8JSG/a D7hQ== X-Gm-Message-State: AOJu0YyBNC0F3SU+6JgiQ++wqYjLyN89c/2EHn+nOq/B+TlNeYv3d0ve Egglm5QFnhQ27IAfaCvFBy47qhebGbQWBVH6RTfDw+i8JVZcuSP8 X-Google-Smtp-Source: AGHT+IEMjH0G7oen3DXa8HmSapnjAFuo090eIB9B6HSpHwWLcDxu+zOu/TpytV5gWux0l4DlISmExw== X-Received: by 2002:ac2:4101:0:b0:52b:60ed:3f0d with SMTP id 2adb3069b0e04-52bb9fe2ae0mr266168e87.60.1717700402607; Thu, 06 Jun 2024 12:00:02 -0700 (PDT) Received: from [1.0.0.7] ([178.155.25.76]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-52bb4216657sm271268e87.137.2024.06.06.12.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jun 2024 12:00:02 -0700 (PDT) Message-ID: Date: Thu, 6 Jun 2024 22:00:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: Assert in heapgettup_pagemode() fails due to underlying buffer change Content-Language: en-US To: Robert Haas Cc: pgsql-hackers References: <7ed10231-ce47-03d5-d3f9-4aea0dc7d5a4@gmail.com> From: Alexander Lakhin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello Robert, 06.06.2024 19:36, Robert Haas wrote: > On Thu, Jun 6, 2024 at 6:00 AM Alexander Lakhin wrote: >> Am I missing something or the the page buffer indeed lacks locking there? > I don't know, but if the locks are really missing now, I feel like the > first question is "which commit got rid of them?". It's a little hard > to believe that they've never been there and somehow nobody has > noticed. > > Then again, maybe we have; see Noah's thread about in-place updates > breaking stuff and some of the surprising discoveries there. But it > seems worth investigating. Yes, my last experiment with memcmp for the whole buffer was wrong, given the comment above heapgettup_pagemode(). I think the correct check would be:              ItemId      lpp;              OffsetNumber lineoff; +ItemIdData      iid;              lineoff = scan->rs_vistuples[lineindex];              lpp = PageGetItemId(page, lineoff); +iid = *((ItemIdData *)lpp); +for (int i = 0; i < 1000; i++) +Assert(memcmp(&iid, lpp, sizeof(iid)) == 0); It significantly alleviates reproducing of the test failure for me. Will try to bisect this anomaly tomorrow. Best regards, Alexander