agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@postgresql.org
Subject: Re: problems with toast.* reloptions
Date: Fri, 20 Jun 2025 14:12:43 -0500
Message-ID: <aFWyq2canGxR2zHo@nathan> (raw)
In-Reply-To: <aFTB8bs_u5WyBReK@paquier.xyz>
References: <aFRxC1W_kZU9OjJ9@nathan>
<aFTB8bs_u5WyBReK@paquier.xyz>
On Fri, Jun 20, 2025 at 11:05:37AM +0900, Michael Paquier wrote:
> On Thu, Jun 19, 2025 at 03:20:27PM -0500, Nathan Bossart wrote:
>> * vacuum_rel() does not look up the main relation's reloptions when
>> processing a TOAST table, which is a problem for manual VACUUMs. The
>> aforementioned bug [0] causes you to sometimes get the expected behavior
>> (because the parameters are overridden before recursing to TOAST), but
>> fixing that bug makes that accidental behavior go away.
>
> Are you referring to the case of a VACUUM pg_toast.pg_toast_NNN? I'm
> not sure that we really need to care about looking up at the parent
> relation in this case. It sounds to me that the intention of this
> paragraph is for the case where the TOAST table is treated as a
> secondary table, not when the TOAST table is directly vacuumed.
> Perhaps the wording of the docs should be improved that this does not
> happen if vacuuming directly a TOAST table.
Yeah, I was mainly thinking of a VACUUM command that recurses to the TOAST
table. Of course, it'd be nice to fix VACUUM pg_toast.pg_toast_NNN, too,
but I'm personally not too worried about that use-case.
>> This doesn't fix VACUUM against a TOAST table directly (e.g., VACUUM
>> pg_toast.pg_toast_5432), but that might not be too important because
>> (PROCESS_TOAST TRUE) is the main supported way to vacuum a TOAST table. If
>> we did want to fix that, though, I think we'd have to teach vacuum_rel() or
>> the relcache to look up the reloptions for the main relation.
>
> This one does not sound that important to me for the case of manual
> VACUUM case directly done on a TOAST table. If you do that, the code
> kind of assumes that a TOAST table is actually a "main" relation that
> has no TOAST table. That should keep the code simpler, because we
> would not need to look at what the parent relation holds when deciding
> which options to use in ExecVacuum(). The autovacuum case is
> different, as TOAST relations are worked on as their own items rather
> than being secondary relations of the main tables.
+1
--
nathan
view thread (44+ messages) latest in thread
Message-ID: <aFWyq2canGxR2zHo@nathan>
Permalink: ../aFWyq2canGxR2zHo@nathan/
Also on: postgresql.org/message-id/aFWyq2canGxR2zHo@nathan
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, michael@paquier.xyz
Subject: Re: problems with toast.* reloptions
In-Reply-To: <aFWyq2canGxR2zHo@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox