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 1pr6Ob-0000Q4-Dj for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Apr 2023 00:19:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pr6Oa-0006NL-7D for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Apr 2023 00:19:00 +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 1pr6OZ-0006NA-Pb for pgsql-hackers@lists.postgresql.org; Tue, 25 Apr 2023 00:18:59 +0000 Received: from mail-io1-xd2d.google.com ([2607:f8b0:4864:20::d2d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pr6OW-001iY4-UM for pgsql-hackers@postgresql.org; Tue, 25 Apr 2023 00:18:58 +0000 Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-760ed95b9e6so113243839f.1 for ; Mon, 24 Apr 2023 17:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20221208.gappssmtp.com; s=20221208; t=1682381936; x=1684973936; 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=8JkWIFh+6IhSxlTKd3lO3wnW97Zwo//FUICc3x5sYMk=; b=1xI1pXUmm/VN1ourgV6jOh/iUu15XzXbsyUKpdsDrmgd+qzUHk/unH8F/VZFzS2xZ8 CO/w/6ier3+5aryD3u69JtNAZM/LivR4XxZ20s+fUHa4V1YfFYn9UnLeNljxNsSr044K P9BpPobYAmn+OZSUhfVygbR6NIPxjcjCuWGgooY4mo8CHldD3Or27DaHjhggdEcyla+e x8pTg13u0XzhLpKqMf6z/i8T3vvxUF7hhe/0eeJb7eGpgFOibJkQC8gA8bZ8oQ9tG1tJ nv+7qx0kQzMTXs3MV6ew/yj1uaoW15bj1fUPGwyresPnuoIDiyV24ujc7onlx+WoVurE R6YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682381936; x=1684973936; 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=8JkWIFh+6IhSxlTKd3lO3wnW97Zwo//FUICc3x5sYMk=; b=h1DE0HXPGOyZ5QKNWMH1Kw+7VkYdZtZJwUW6hEMHfUQrjikTMR7rFWgGpIvXH71DSc SCL/vW4MMZnLg4DxPLxa8wnmKY6mOUvIm5RJfhA1r77ybKATV/jmHlC5lCWZu9VEB5dl 7GW4P095AjqNYuUFfr3T+cnGQa0huktnHEHexN45ZZk8mTlHTFyFsFfeOD/lirlSKsu+ LjzbDuX064DEa5cgAsfp5cwxxHVO0WzfU508FV3Kkssu/056y6407XJ6u1OnJqhWPUQb BTxWFB1fRu/z34KygIJQ6YlABlMlyjZXeoAB1jOS7z7tWPGiDJhtT+f1Qtn+V/+4R3v4 /n6A== X-Gm-Message-State: AAQBX9e9oOm1FLR12bDnP+7tRXH3M8ipq8ftyEaO3jIYhaGvgrzg1+3K pFwR6o+FTBJ1JUNLE+vaLyazow== X-Google-Smtp-Source: AKy350a3LHNCGz1etO+IQf2aI4p78oqJ9tpV9VmrcwEqcO8TdAGjkKABX75c/JXF1SzdrtaQ75lPNw== X-Received: by 2002:a5e:dc0c:0:b0:71b:3544:887 with SMTP id b12-20020a5edc0c000000b0071b35440887mr7239994iok.10.1682381936065; Mon, 24 Apr 2023 17:18:56 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id q2-20020a5ea602000000b0075c24bc7f11sm3532423ioi.48.2023.04.24.17.18.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Apr 2023 17:18:55 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 927AF80055C; Mon, 24 Apr 2023 19:18:54 -0500 (CDT) Date: Mon, 24 Apr 2023 19:18:54 -0500 From: Justin Pryzby To: Michael Paquier Cc: Soumyadeep Chakraborty , Zhihong Yu , pgsql-hackers@postgresql.org, Ashwin Agrawal , vanjared@vmware.com Subject: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables 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 Thu, Mar 30, 2023 at 12:07:58AM -0500, Justin Pryzby wrote: > On Mon, Mar 27, 2023 at 11:34:36PM -0500, Justin Pryzby wrote: > > On Tue, Mar 28, 2023 at 09:13:10AM +0900, Michael Paquier wrote: > > > On Mon, Mar 20, 2023 at 09:30:50AM +0900, Michael Paquier wrote: > > > > Did you check dump and restore flows with partition > > > > trees and --no-table-access-method? Perhaps there should be > > > > some regression tests with partitioned tables? > > > > > > I was looking at the patch, and as I suspected the dumps generated > > > are forgetting to apply the AM to the partitioned tables. > > > > The patch said: > > > > + else if (RELKIND_HAS_TABLE_AM(relkind) || relkind == RELKIND_PARTITIONED_TABLE) > > > > pg_dump was missing a similar change that's conditional on > > RELKIND_HAS_TABLE_AM(). It looks like those are the only two places > > that need be be specially handled. > > > > I dug up my latest patch from 2021 and incorporated the changes from the > > 0001 patch here, and added a test case. > > > > I realized that one difference with tablespaces is that, as written, > > partitioned tables will *always* have an AM specified, and partitions > > will never use default_table_access_method. Is that what's intended ? > > > > Or do we need logic similar tablespaces, such that the relam of a > > partitioned table is set only if it differs from default_table_am ? > > Actually .. I think it'd be a mistake if the relam needed to be > interpretted differently for partitioned tables than other relkinds. > > I updated the patch to allow intermediate partitioned tables to inherit > relam from their parent. > > Michael wrote: > > .. and there are quite more points to consider. > > What more points ? There's nothing that's been raised here. In fact, > your message last week is the first comment since last June .. Michael ?