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: Tue, 24 Jun 2025 11:38:41 -0500
Message-ID: <aFrUkYVyATVk2nsD@nathan> (raw)
In-Reply-To: <aFozXwRQu3LaDELy@paquier.xyz>
References: <aFRxC1W_kZU9OjJ9@nathan>
<aFTB8bs_u5WyBReK@paquier.xyz>
<aFnATDLLdP0m-fGb@nathan>
<aFozXwRQu3LaDELy@paquier.xyz>
On Tue, Jun 24, 2025 at 02:10:55PM +0900, Michael Paquier wrote:
> On Mon, Jun 23, 2025 at 03:59:56PM -0500, Nathan Bossart wrote:
>> Here is a very rough proof-of-concept patch set for this. AFAICT there are
>> a few options we cannot fix on the back-branches because there is no way to
>> tell whether it is set or has just picked up the default. On v18 and
>> newer, we could use isset_offset, but that doesn't exist on older versions.
>> (I haven't looked closely, but I'm assuming that back-patching isset_offset
>> isn't an option.)
>
> Hmm. I am wondering if we need to be aggressive about this set of
> changes at all in the back branches. It's been broken for a long time
> without anybody really complaining about the fact that reloptions
> being set or not influenced the outcome in the context of autovacuum,
> so perhaps there is a good argument for keeping all that in v19. My
> conservative 2c.
Yeah, I'm tempted to even ask how folks feel about removing the toast.*
reloptions. Maybe there's some simple cases that work well enough, but
AFAICT any moderately-complicated setup basically doesn't work at all. In
any case, writing out this patch set has got me on the fix-on-HEAD-only
bandwagon.
>> I would like to explore the "option 2" from upthread [0] for v19. I think
>> that is a better long-term solution, and it may allow us to remove the
>> table_toast_map in autovacuum.
>
> It would be nice to have some tests here to check the state of the
> options used? My best guess would be a DEBUG1 entry combined with a
> scan of the logs generated and an aggressive autovacuum worker
> spawn to check that the options generated are what we expect for the
> relations autovacuum picks up.
Eh... I agree that's probably how we'd have to test it with the existing
tools, but it sure sounds like a recipe for a flaky test.
--
nathan
view thread (44+ messages) latest in thread
Message-ID: <aFrUkYVyATVk2nsD@nathan>
Permalink: ../aFrUkYVyATVk2nsD@nathan/
Also on: postgresql.org/message-id/aFrUkYVyATVk2nsD@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: <aFrUkYVyATVk2nsD@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