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 1sqwRG-00EE45-OE for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Sep 2024 15:17:54 +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 1sqwRF-00Bkae-C7 for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Sep 2024 15:17:53 +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 1sqwRF-00BkZj-24 for pgsql-hackers@lists.postgresql.org; Wed, 18 Sep 2024 15:17:53 +0000 Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sqwRD-001qWT-4I for pgsql-hackers@lists.postgresql.org; Wed, 18 Sep 2024 15:17:52 +0000 Received: by mail-io1-xd31.google.com with SMTP id ca18e2360f4ac-82ce603d8b5so288794639f.0 for ; Wed, 18 Sep 2024 08:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726672669; x=1727277469; darn=lists.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=Dts7VHlYGTBNB15uodUFxbNJPgVdppdTSMWuqYU1zdM=; b=iIguW6zLZj8vMfwujK3ZstHIxkEiHn+RAQsvHFRQUcdiM8G1SnOZ5ay8jbOS7oyAKB gvQy5IAbdj0Kz2g2WrbEgIJv6D01i1T+X5oiYJaPFqFwOeOjq4vceuCSj0DdmK+5GKUk bE6NMd+4QLC/nv+/VAZI/0m/F965RGBj1f/Xi21owR3wEtmnx5XfWNYAJvbtABlG4VOM BIbqcRdcYRIK7OJOcGrPDdBoquviW5NhXvIljlzR0ZMo7bt/Yd+agd66SokKT9RJhhK5 Fk/cGSWLHH/EXw/mEWBGGn/KIUPpPHp+jPXCTQScDkJLo93/Q3SRNe+1t9m5ZsogWIgF yujA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726672669; x=1727277469; 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=Dts7VHlYGTBNB15uodUFxbNJPgVdppdTSMWuqYU1zdM=; b=k9hmvD3yUz4m1jbolXQgRC9r8H0YjnKHjxzHSxa1qRvOyQwPgTUYylhYB6uXsCxy6w o/Ym8+xy/mUfRgmgPL0Hdnmg1x/JGkfF3OOS15tBdB8bHg2pYXLEJ2UZCIEQHA0NMdi8 nndJcrHoEgarFZVNm4sspSDLvPHfiIyCjd55DlTX48mzqRklXrDNGvlVxW4LRPBaVkuF CRx3U4UyptretNKNnhf3SNIAQkJkafH3RlWpUJ6tSc7RnakFpxlQeYkvuXgR3LeV5O+e EvTcQw135vU+RbpdIuMSwBi/QG4zcGsRnLMb4OKJZ/NO07WUJEOg2SQRjxLSAEHI5Gef E7Pw== X-Forwarded-Encrypted: i=1; AJvYcCUPWcYzORYtfR/0DV0bMdoKUDjr+kD5HNC2/lQlx9V+uQ2fsqYnoLXVUv5/H0eStMyJJ3gKT/QSfjk7z/fH@lists.postgresql.org X-Gm-Message-State: AOJu0YwaUZdq3+6Ks5L9SZoukHP3BkSDUiCTtRSXehxecuzY5GQlF3mL uRa919A2XuN8GptlJTWPnbovlFlgBqnFY/Gi20UbaFeGOXG7OP5n X-Google-Smtp-Source: AGHT+IFYjIwZRKG+5B2GUaTPNJjraTZSXpapmFqyvmy5h8LnlVXuulr0+HT78NX4E9pWv+ILiQ9lWA== X-Received: by 2002:a05:6602:6d8b:b0:82a:a4e7:5544 with SMTP id ca18e2360f4ac-82d1f8e18c6mr2167468039f.9.1726672669463; Wed, 18 Sep 2024 08:17:49 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4d37ed34b36sm2504663173.124.2024.09.18.08.17.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Sep 2024 08:17:48 -0700 (PDT) Date: Wed, 18 Sep 2024 10:17:47 -0500 From: Nathan Bossart To: Michael Paquier Cc: "David G. Johnston" , Postgres hackers Subject: Re: Partitioned tables and [un]loggedness 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 10, 2024 at 09:42:31AM +0900, Michael Paquier wrote: > On Mon, Sep 09, 2024 at 03:56:14PM +0900, Michael Paquier wrote: >> How about inventing a new ATT_PARTITIONED_TABLE and make a clean split >> between both relkinds? I'd guess that blocking both SET LOGGED and >> UNLOGGED for partitioned tables is the best move, even if it is >> possible to block only one or the other, of course. > > I gave it a try, and while it is much more invasive, it is also much > more consistent with the rest of the file. This looks reasonable to me. Could we also use ATT_PARTITIONED_TABLE to remove the partitioned table check in ATExecAddIndexConstraint()? -- nathan