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 1uU8HW-00G9Ze-2Y for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jun 2025 18:22: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 1uU8HU-00E6hm-7Y for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jun 2025 18:22:04 +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 1uU8HT-00E6he-Sf for pgsql-hackers@lists.postgresql.org; Tue, 24 Jun 2025 18:22:04 +0000 Received: from mail-il1-x134.google.com ([2607:f8b0:4864:20::134]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uU8HS-003s7w-1b for pgsql-hackers@postgresql.org; Tue, 24 Jun 2025 18:22:04 +0000 Received: by mail-il1-x134.google.com with SMTP id e9e14a558f8ab-3ddda8e419bso751375ab.0 for ; Tue, 24 Jun 2025 11:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750789319; x=1751394119; 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=iWCIL0oHgVYvR+gg+uIJ3SR97sW9n3PKp4UoiXXlpyQ=; b=c4JsTnl9aoT0p/IviyTBGpStmMTUZ1I12DJt8FcjagurC8EvamdANwFJFY32oVrjV1 5bKHQbJ9Qkzxq3xt4COyWKDLNXPvoPnr0WBFECaeWiNrwjBLZGmodNqOxYOZEJ0gY3R1 bfpHZGCzhZUgTYCaYN56vqx5dtVA/DN8vxk4b2dIyqVI70L+pETC6SDmPp/ErTpbDxNE 0cRhg52qrRzpdWwbmNp9ffMzDWUdD6DP79SIjU9sA8qAU9Su24cPw3R0/Y0PWtWEmKAs 9fwX08HbAO2nxOj0DsyEL+wMru9pU6EwHyghLPu56upuBqokG0aEDbGi6F7AAPArjHxg g1lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750789319; x=1751394119; 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=iWCIL0oHgVYvR+gg+uIJ3SR97sW9n3PKp4UoiXXlpyQ=; b=hcLE1OzgBm5so//jVhFQpHJ+5Pquh30w9FLFmJynVHd+sDhw4ihKJWuM4z/ydFd4zN L5uz6qNf8bcM1Rb9o9KrH5ogUIJlpeydjntMUoMFonZ93zyCycCGNpCjda7csCdWAbcD xGj+SBxY939mvVDHuwo2mGP3Xia7D8S9qwb2bW1IxArM2tCneB7U9v72czabMZGg/SqG 1T1OFiG2AmJA0ePuOtlNhWgE7BVjNnxjMI3MZZY+FxFxH7/Clgztc6jZNV5TornFpbYH VmRZhn3nlsiwC+0gz3KzFAX1HeO/d+0nSty4MUrIh60H2fC2YtKgdDuZ0aSlqDcIrHOO 3BUQ== X-Forwarded-Encrypted: i=1; AJvYcCX3RWqwvnuAf9KpEroKf+N0uWMlnKJmohl4ebxDYS2Xv6xeHtv4aF/STSlke/NClKU/qZg8eR3F8rwYLvDY@postgresql.org X-Gm-Message-State: AOJu0YyYSF2kcRInpUZg+P0+8WHkLrY0xei1RCaASF9IVBlrLiSMisGf tJTzbZwIO5xTqLxzPsRfcpGqrSkAH93ni5ELW82H9P469RxBhWfO1J3q X-Gm-Gg: ASbGncsPGWVGba2q8+rJclHC1WuZmvZEM7x7CWsr5ko+DZlBjDmRbDSXR2BI4wQ0Moa VBbT7YrLZcQ77xE1tGKNGmhmJ0Q256ObwaUIW5/3mvXtoKb5Zcr6ndr1ZexQkDmXs65HpizsVLB UioytZ6IudWhkSmdxSXT9PtQq25QtXCy2mUJIT3yd4erQ+sszoSPcZlL6DFntbj8bSaYHbo0x6F S9PsBbTiCJMPo3UarWbbNgI+pTwslfe88EpJkl9IY4uBhVh8aEnSBVSjWYS8LuZ3mc1Df6gWKqM s/K4oTvqiEesVcCeRCsEfI0w+kx+OKMo/e1hEkVMw1r1pjmTEKNFl+k24a8NQT69x8uJs8jP95i kfcLNPcLv6u2Vb5cabM4GN+ufu04K7To8+I0yysXSiutPRD6Bpa5i X-Google-Smtp-Source: AGHT+IEHKYJ78iB8dJ1Puer4W3c9Yp139iMlfAyTmWTJkeh4PD5g7tqB7J0biPz76lLfICbn2XwA/w== X-Received: by 2002:a05:6e02:214d:b0:3dc:7b3d:6a45 with SMTP id e9e14a558f8ab-3df32a29005mr212565ab.0.1750789318808; Tue, 24 Jun 2025 11:21:58 -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-3de37618a3esm38633545ab.8.2025.06.24.11.21.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 11:21:58 -0700 (PDT) Date: Tue, 24 Jun 2025 13:21:56 -0500 From: Nathan Bossart To: shihao zhong Cc: Michael Paquier , pgsql-hackers@postgresql.org Subject: Re: problems with toast.* reloptions 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 Mon, Jun 23, 2025 at 10:59:51AM -0500, Nathan Bossart wrote: > On Sat, Jun 21, 2025 at 11:45:25PM -0400, shihao zhong wrote: >> 2) When updating a table's relopt, also update the relopt of its >> associated TOAST table if it's not already set. Similarly, when >> creating a new TOAST table, it would inherit the parent's relopt. >> >> Option 2 seems more reasonable to me, as it avoids requiring customers >> to manually resolve these options, when they have different settings >> for the parent and TOAST tables." > > I like this one, but since it won't fix existing clusters, it might only be > workable for v19. Actually, I think there's a problem with this approach. If we set the reloption for both the main relation and the TOAST table, then we won't know what to do for RESET. Take the following examples: ALTER TABLE test SET (vacuum_truncate = false); ALTER TABLE test RESET (vacuum_truncate); ALTER TABLE test SET (vacuum_truncate = false); ALTER TABLE test SET (toast.vacuum_truncate = false); ALTER TABLE test RESET (vacuum_truncate); After executing the commands in the first stanza, you'd expect the vacuum_truncate reloption to be unset for both the main relation and its TOAST table. After the second one, you'd expect it to be set for only the TOAST table. But unless there's some way to know the source of the TOAST table's reloption, we can't know which behavior is correct at RESET time. -- nathan