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 1slaLm-0001x0-7X for pgsql-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 20:42:06 +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 1slaKm-0000Yf-5O for pgsql-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 20:41:04 +0000 Received: from magus.postgresql.org ([87.238.57.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 1slaKl-0000YX-Kq for pgsql-hackers@lists.postgresql.org; Tue, 03 Sep 2024 20:41:04 +0000 Received: from mail-il1-x12f.google.com ([2607:f8b0:4864:20::12f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slaKg-0000Y9-1X for pgsql-hackers@postgresql.org; Tue, 03 Sep 2024 20:41:03 +0000 Received: by mail-il1-x12f.google.com with SMTP id e9e14a558f8ab-39d3636e955so19861615ab.3 for ; Tue, 03 Sep 2024 13:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725396056; x=1726000856; darn=postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Ekp5eIbW07EGzna+KP/USxYy+1ARKfEFNHnCJBRJlTk=; b=TtzxltzUrrDe7PMFEimhKyO+4OuBt0PL52l3NCp+hvA6H8Qzi/VbZCCd3cglR1mYxY Q2N+YlTUkDb1mAFrgFRrrtHvzKXkCCHQA4nWzBjwMBz+4bBJHkufWnuVU7rGk0L6RnDC 3uqjjPaBqa1kgG2X34bFeDFoBVFIhXqqqPfuBQIT2OSp1lXIPEnonuugWa+iq7IbF2F+ dK8qItie6lVs1uDDrLx93ZbNOzpP3F6wfbN5qwGGueP4Tij7UjWgIe6Bd3yhJazGGiWW XVQ9CDV/kcuaL3iOA7z73g8h9DWChBVs3778++VAa7u99o9wPavbaAKhaWOmKp5xF/80 c+qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725396056; x=1726000856; h=in-reply-to: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=Ekp5eIbW07EGzna+KP/USxYy+1ARKfEFNHnCJBRJlTk=; b=rhox7rVMGq1sqjZCvAQ3nGF76MSEi8LacYXHbVuyK3Y5Vbv/72ICL089NAGBtbljzN YZQ5XXcJxP69ep8H0ja5A0Bo46nai+D3GBcO1gKYlBC9wBitA7BeZ1JAkFxhnNaEMRfp a5yU49myna/O/f3IokQZDMr2njFa/mASHkTXdFk1fsARhgqpwit8v+uJCHRM+JRETBzN o88XCQPjgvXifP7SvipjWTiwU6wupAB6sXsdap6NphM0M+dmTZZPZ+E5ZkIAPUiP2QJJ Cc150OvlLe1PhM5clmnmWJk81R6pjlKzIdJNnHnNuBpy0ySjj3EXirXA95vToCo2maaM 3EzQ== X-Forwarded-Encrypted: i=1; AJvYcCU3N5yJBnfO3HWyX71AjA54an6BmRW/Y4MMgrFJAo/0P3vvmfN3rjhxwdXYCBpD2QfumQOVfr63a7SMp2pE@postgresql.org X-Gm-Message-State: AOJu0Yz81I1Do/k0zP8oj8WmbhFPSOXi5OUQCpK+ymIPoDrA0QYoKpef sOQaZfOefMKJbe8xnZ1S0I4aeEfUPazZ4ZeRm5rI4HmoVNmW6IiB X-Google-Smtp-Source: AGHT+IE2eFzpfXhMp2T4PBmDSFST97XJbUiz6LJUtt8f2MJxkMbgWgF9IwbCZmA1yp12bBJm17blrA== X-Received: by 2002:a05:6e02:1d0c:b0:39d:1694:d261 with SMTP id e9e14a558f8ab-39f4f68e352mr150508375ab.12.1725396056000; Tue, 03 Sep 2024 13:40:56 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-39f3b05bf51sm32934035ab.86.2024.09.03.13.40.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Sep 2024 13:40:55 -0700 (PDT) Date: Tue, 3 Sep 2024 15:40:53 -0500 From: Nathan Bossart To: Matthias van de Meent Cc: Robert Haas , Ayush Vatsa , PostgreSQL Hackers , Michael Paquier Subject: Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch Message-ID: References: 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 On Tue, Sep 03, 2024 at 10:19:33PM +0200, Matthias van de Meent wrote: > On Fri, 30 Aug 2024, 23:06 Nathan Bossart, wrote: >> Another related inconsistency I just noticed in pageinspect: >> >> postgres=# select t_data from heap_page_items(get_raw_page('s', 0)); >> t_data >> -------------------------------------- >> \x0100000000000000000000000000000000 >> (1 row) >> >> postgres=# select tuple_data_split('s'::regclass, t_data, t_infomask, t_infomask2, t_bits) from heap_page_items(get_raw_page('s', 0)); >> ERROR: only heap AM is supported > > I don't think this is an inconsistency: > > heap_page_items works on a raw page-as-bytea (produced by > get_raw_page) without knowing about or accessing the actual relation > type of that page, so it doesn't have the context why it should error > out if the page looks similar enough to a heap page. I could feed it > an arbitrary bytea, and it should still work as long as that bytea > looks similar enough to a heap page. > tuple_data_split, however, uses the regclass to decode the contents of > the tuple, and can thus determine with certainty based on that > regclass that it was supplied incorrect (non-heapAM table's regclass) > arguments. It therefore has enough context to bail out and stop trying > to decode the page's tuple data. My point is really that tuple_data_split() needlessly ERRORs for sequences. Other heap functions work fine for sequences, and we know it uses the heap table AM, so why should tuple_data_split() fail? I agree that the others needn't enforce relkind checks and that they might succeed in some cases where tuple_data_split() might not be appropriate. -- nathan