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 1sjgT9-002xMX-B8 for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Aug 2024 14:49:51 +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 1sjgT7-003PjT-Fz for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Aug 2024 14:49:50 +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 1sjgT7-003PjL-6L for pgsql-hackers@lists.postgresql.org; Thu, 29 Aug 2024 14:49:49 +0000 Received: from mail-il1-x130.google.com ([2607:f8b0:4864:20::130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sjgT4-002655-Fo for pgsql-hackers@lists.postgresql.org; Thu, 29 Aug 2024 14:49:49 +0000 Received: by mail-il1-x130.google.com with SMTP id e9e14a558f8ab-39d2e4d73bcso3051945ab.1 for ; Thu, 29 Aug 2024 07:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724942986; x=1725547786; 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=gjz8SDdRYVv4U+pU5TeFRvi6PRdu0zgPrUTYIPF3lp4=; b=MA0UKxk5nOQO3k9bmQ2cUco9DLnRFpSxOQ7n03U3PwBH/PAlqxh02ZDpUqnIELC6jc 5f74pVLk2qvleVJPtXddo/NSZjgUWS+N9TLqaIXwkcZRLmVqlAre0z7ZKswP8tO4tsnU 7iNTP0A9niWarlfe7pV8YLNVoJna4XTCc2Que4/uWtCaEYumJl9+0j3SfNqnYXfQ55O8 h8OBmKJmID/dDyhEQsF4+LIQcspv/ZpAla70bi0ifryEcH1EDBRwUD+QNFN8Ow72tEHk 5xtHQqGuToK5EudWX/EJKDdlgWLm54pZMUBi9AYIt6bEIkKGxsl7onKNF/+5i0P967kL FqoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724942986; x=1725547786; 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=gjz8SDdRYVv4U+pU5TeFRvi6PRdu0zgPrUTYIPF3lp4=; b=HoyOysX+sfwWRVs1pt3qEneEyosHkMRia3Rpz2FU8tIAa8wI9ttxF5xnnDTSSqNPrm cCJSHBCh2PmuE4CJZ5fKIhJC+dzhcRqQzzgiD1WEZitgmyrohhrtUJC41FZV9cwkggnh rgUj361P6+ABLBp38nGB/tpaM0i8hWBY+r+YYw+dvbDVMrqKwUz1hPBfUioEXMgyU4br vF/1bkBeXkhdga3oCmilvLES6SjirxirxxQRTaywRZ0qnpiinKUSBMY316N9dWddW7ou 7hHhSbXPaPtdkyklI2TqMAsuTrgI/FmEaEe7SNYyxhT4I0BW5C8Dz7S4uLUqWlnbIncd ee9w== X-Forwarded-Encrypted: i=1; AJvYcCWW9Ldl0h/U0S4BNCr/vGksvCmiIXAeJYuiY8oE2pY4Q/+kcAXR0Qxa/wxObcm1T4PMs5nlxAwjzuBKv9vg@lists.postgresql.org X-Gm-Message-State: AOJu0YyKSQoJXZBEEiSNqbBMIR/Q+LWvWwxdJAKuj1knzzTO/gRlI3IJ zDAJPHC3nEDJodF1cw8R9yBoGhWZpzXTYRAmhxzhpQAikC3Qn64z X-Google-Smtp-Source: AGHT+IGnyEwPYjpUv/Vq9kxj/X7EQ9Q6vkR7mOSyTnd5iDgPh1GbrRAa3YNwdXybVL2TfBevYeTYfA== X-Received: by 2002:a05:6e02:1a01:b0:39f:36f3:1959 with SMTP id e9e14a558f8ab-39f377d827emr40779565ab.3.1724942986072; Thu, 29 Aug 2024 07:49:46 -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-39f3af969dfsm3209075ab.14.2024.08.29.07.49.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2024 07:49:45 -0700 (PDT) Date: Thu, 29 Aug 2024 09:49:44 -0500 From: Nathan Bossart To: Michael Paquier Cc: "David G. Johnston" , Postgres hackers Subject: Re: Partitioned tables and [un]loggedness Message-ID: References: <20240424202640.GB861150@nathanxps13> 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, Aug 29, 2024 at 03:44:45PM +0900, Michael Paquier wrote: > On Tue, Aug 27, 2024 at 04:01:58PM -0500, Nathan Bossart wrote: >> My current thinking is that it would be better to disallow marking >> partitioned tables as LOGGED/UNLOGGED and continue to have users explicitly >> specify what they want for each partition. It'd still probably be good to >> expand the documentation, but a clear ERROR when trying to set a >> partitioned table as UNLOGGED would hopefully clue folks in. > > The addition of the new LOGGED keyword is not required if we limit > ourselves to an error when defining UNLOGGED, so if we drop this > proposal, let's also drop this part entirely and keep DefineRelation() > simpler. +1 > Actually, is really issuing an error the best thing we can > do after so many years allowing this grammar flavor to go through, > even if it is perhaps accidental? relpersistence is marked correctly > for partitioned tables, it's just useless. Expanding the > documentation sounds fine to me, one way or the other, to tell what > happens with partitioned tables. IMHO continuing to allow partitioned tables to be marked UNLOGGED just preserves the illusion that it does something. An ERROR could help dispel that misconception. -- nathan