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
