Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nZPAd-0000Nz-EN for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Mar 2022 03:38:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nZPAc-00064o-2q for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Mar 2022 03:38:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nZPAb-00064f-Mo for pgsql-hackers@lists.postgresql.org; Wed, 30 Mar 2022 03:38:53 +0000 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nZPAZ-0003lb-Fy for pgsql-hackers@postgresql.org; Wed, 30 Mar 2022 03:38:52 +0000 Received: by mail-pf1-x42f.google.com with SMTP id s11so17605794pfu.13 for ; Tue, 29 Mar 2022 20:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tOSD8R+z3DBTRMVuMOow6tCvAOkP6ZN6E0MQu4nI0w4=; b=KP0dPM33pfdZ84CqYf3Zcu9a3u/TgH3RwmNeTSzrBVKcm+T42OPZtkT1oP1ool65dj +tLUCUaTA/JaOHLTSKEeeNj/4In6vd2kxhumuf1j4uBlf0Mw7l2K2E0OjF0MrA2R6hKk sxEEjptlGMOMjF3MidAfa0kM6l6QLk9IsQizfwMiwiVnNYNS1GhrHHEyUFJo1fzOW9gs +GyE2hQNSF+Ulb+uCg/nHxhPefpH/wzCQYKmyHafVoFV4aPKKxLH/L6o7KKlRDyd39SE 67F1KvAdKX51Iid6JwPn86NrF/n3hH8m1XqptN9F+P3Oc1XTzmVoP16SrJssTzz1O3MR sSpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tOSD8R+z3DBTRMVuMOow6tCvAOkP6ZN6E0MQu4nI0w4=; b=oGXYH9AYxar9TFNp+9Pcl9DaFJkxqgZSUbXxVqxUMz0sBswo4INFlRmNHzD7xoxIHX xGX/zCqFY3VszCFFjIJMS32l1uv+IOCBYp8gkLVbxx+jJMBuUSeETmoeHyhuP4tl8JmH +5qiLb7cH4VbIwS0OubjfM+K//ilnwg+e+ezCQGA28SsyBGwj/LsH9fDKsFYI7/JkzGf 7CqqqpO3rd+2AacvqAfE42agCcepMBWrdrL3T7TXhBqybK4y3+iv/eMhX+FNINR4Yo8I 2QYnpUGu9PU4ras3/yGpC5qgnb6XpCx7Ebo02fhSlNC2c1kiBQbMzaklSzmb2E1/O2VI JNRA== X-Gm-Message-State: AOAM533R04ukuOpHH8rHjxgv8LI2nVYKs2Ir0tWHWZ4CWvTOZeKdyYlp IWlkSwPdScBvOSjcOm34v4Q= X-Google-Smtp-Source: ABdhPJyeeukGLeI5LY03Q09mYckSRrAmcF6+KlT+cv1KTkWCDkHCPGb16OOGlLtCHc4eHYPSY8Dvwg== X-Received: by 2002:a63:1f55:0:b0:382:65eb:3073 with SMTP id q21-20020a631f55000000b0038265eb3073mr4547223pgm.624.1648611530463; Tue, 29 Mar 2022 20:38:50 -0700 (PDT) Received: from jrouhaud (2001-b011-1005-b35e-e97a-500e-8eac-60c0.dynamic-ip6.hinet.net. [2001:b011:1005:b35e:e97a:500e:8eac:60c0]) by smtp.gmail.com with ESMTPSA id n3-20020a056a0007c300b004fa3e9f59cdsm20327266pfu.39.2022.03.29.20.38.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Mar 2022 20:38:48 -0700 (PDT) Date: Wed, 30 Mar 2022 11:38:43 +0800 From: Julien Rouhaud To: Maxim Orlov Cc: Michael Paquier , Peter Geoghegan , Robert Haas , Alexander Lakhin , Justin Pryzby , Daria Lepikhova , PostgreSQL Hackers Subject: Re: Assert in pageinspect with NULL pages Message-ID: <20220330033843.v325dpsl2dfjspl2@jrouhaud> References: <186c0dc2-cf36-c45c-7933-676956821d11@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Mon, Mar 28, 2022 at 08:29:29PM +0300, Maxim Orlov wrote: > I've suddenly found that the test in this patch is based on a fact that > heap pages don't have PageSpecial or it is of different size with btree > pages Special area: > > CREATE TABLE test1 (a int8, b int4range); > > SELECT bt_page_items(get_raw_page('test1', 0)); > > > In the current state is is so, but it is not guaranteed. For example, in > the proposed 64xid patch [1] we introduce PageSpecial into heap pages and > its size on occasion equals to the size of btree page special so check from > above is false. Even if we pass heap page into pageinspect pretending it is > btree page. So the test will fail. > > > Generally it seems not only a wrong test but the consequence of a bigger > scale fact that we can not always distinguish different AM's pages. So I'd > propose at least that we don't come to a conclusion that a page is valid > based on PageSpecial size is right. We don't assume that the page is valid, or of the correct AM, just based on the special area size. We do reject it if the size is invalid, but we also have other tests based on what's actually possible to test (checking flag sanity, magic values and so on). Note that Peter G. suggested to add more checks for btree based on palloc_btree_page(), did you check if those were enough to fix this test with the 64bits xid patchset applied?