From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: problems with toast.* reloptions |
Date: | 2025-06-24 05:10:55 |
Message-ID: | aFozXwRQu3LaDELy@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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.
>
> [0] https://postgr.es/m/aFl598epAdUrrv0y%40nathan
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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-06-24 05:11:33 | Re: Minor patch; missing comment update in worker.c |
Previous Message | shveta malik | 2025-06-24 05:07:00 | Re: Logical Replication of sequences |