From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
---|---|
To: | nathandbossart(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org, michael(at)paquier(dot)xyz |
Subject: | Re: add PROCESS_MAIN to VACUUM |
Date: | 2023-03-06 22:09:58 |
Message-ID: | 20230306220958.rk4b4msmybi6hm56@liskov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 06, 2023 at 01:13:37PM -0800, Nathan Bossart wrote:
> On Mon, Mar 06, 2023 at 03:48:28PM -0500, Melanie Plageman wrote:
> > On Mon, Mar 6, 2023 at 3:27 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> >> On Mon, Mar 06, 2023 at 02:40:09PM -0500, Melanie Plageman wrote:
> >> > I noticed in vacuum_rel() in vacuum.c where table_relation_vacuum() is
> >> > called, 4211fbd84 changes the else into an else if [1]. I understand
> >> > after reading the commit and re-reading the code why that is now, but I
> >> > was initially confused. I was thinking it might be nice to have a
> >> > comment mentioning why there is no else case here (i.e. that the main
> >> > table relation will be vacuumed on the else if branch).
> >>
> >> This was a hack to avoid another level of indentation for that whole block
> >> of code, but based on your comment, it might be better to just surround
> >> this entire section with an "if (params->options & VACOPT_PROCESS_MAIN)"
> >> check. WDYT?
> >
> > I think that would be clearer.
>
> Here's a patch. Thanks for reviewing.
> diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
> index 580f966499..fb1ef28fa9 100644
> --- a/src/backend/commands/vacuum.c
> +++ b/src/backend/commands/vacuum.c
> @@ -2060,23 +2060,25 @@ vacuum_rel(Oid relid, RangeVar *relation, VacuumParams *params, bool skip_privs)
I would move this comment inside of the outer if statement since it is
distinguishing between the two branches of the inner if statement.
Also, I would still consider putting a comment above that reminds us that
VACOPT_PROCESS_MAIN is the default and will vacuum the main relation.
> /*
> * Do the actual work --- either FULL or "lazy" vacuum
> */
> - if ((params->options & VACOPT_FULL) &&
> - (params->options & VACOPT_PROCESS_MAIN))
> + if (params->options & VACOPT_PROCESS_MAIN)
> {
> - ClusterParams cluster_params = {0};
> + if (params->options & VACOPT_FULL)
> + {
> + ClusterParams cluster_params = {0};
>
> - /* close relation before vacuuming, but hold lock until commit */
> - relation_close(rel, NoLock);
> - rel = NULL;
> + /* close relation before vacuuming, but hold lock until commit */
> + relation_close(rel, NoLock);
> + rel = NULL;
>
> - if ((params->options & VACOPT_VERBOSE) != 0)
> - cluster_params.options |= CLUOPT_VERBOSE;
> + if ((params->options & VACOPT_VERBOSE) != 0)
> + cluster_params.options |= CLUOPT_VERBOSE;
>
> - /* VACUUM FULL is now a variant of CLUSTER; see cluster.c */
> - cluster_rel(relid, InvalidOid, &cluster_params);
> + /* VACUUM FULL is now a variant of CLUSTER; see cluster.c */
> + cluster_rel(relid, InvalidOid, &cluster_params);
> + }
> + else
> + table_relation_vacuum(rel, params, vac_strategy);
> }
> - else if (params->options & VACOPT_PROCESS_MAIN)
> - table_relation_vacuum(rel, params, vac_strategy);
>
> /* Roll back any GUC changes executed by index functions */
> AtEOXact_GUC(false, save_nestlevel);
- Melanie
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-03-06 22:10:10 | Re: On login trigger: take three |
Previous Message | Nathan Bossart | 2023-03-06 22:00:27 | Re: Improve WALRead() to suck data directly from WAL buffers when possible |