From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | shihao zhong <zhong950419(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fixes inconsistent behavior in vacuum when it processes multiple relations |
Date: | 2025-06-20 19:16:46 |
Message-ID: | aFWznvZtYZ3VJxgi@nathan |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 20, 2025 at 10:34:19AM +0900, Michael Paquier wrote:
> Hmm. I like the simplicity of option 2) for the purpose the back
> branches and the post-feature-freeze v18.
Yeah, let's do this for now.
> However, Option 1) would be my go-to option for HEAD (as of v19
> opening for business), but I think that we should harden the code more
> than suggested and treat all VacuumParams as purely input arguments
> rather keeping some pointers to it depending on the code path we are
> dealing with, so as no callers of these inner routines is surprised by
> changes that may happen internally. Hence, reading the code of v2,
> I'd suggest to apply the same rule to vacuum_get_cutoffs(),
> do_analyze_rel() and heap_vacuum_rel(). Except if I am missing
> something, it looks like all these calls should be OK with this new
> policy. This implies also changing relation_vacuum() in tableam.h,
> which can be a HEAD-only change anyway.
Sounds reasonable to me.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Anne Struble | 2025-06-20 19:27:01 | Memory allocation error DDL invalidation (seen with 15.13 & 16.9) |
Previous Message | Nathan Bossart | 2025-06-20 19:12:43 | Re: problems with toast.* reloptions |