From: | shihao zhong <zhong950419(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fixes inconsistent behavior in vacuum when it processes multiple relations |
Date: | 2025-06-18 18:48:16 |
Message-ID: | CAGRkXqTp9k_7X1OqqQSnVfoyGxAM3SQ083CcyaezBg9qQ8i+qg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> That leads me to think (1) might be the better option, although I'm not too
>> wild about the subtlety of the fix.
Thanks for your feedback. New patch is attached. I also updated the
signature of do_analyze_rel for the same reason.
On Wed, Jun 18, 2025 at 12:31 PM Nathan Bossart
<nathandbossart(at)gmail(dot)com> wrote:
>
> On Wed, Jun 18, 2025 at 11:15:31AM -0400, shihao zhong wrote:
> > I investigated the code and found a small bug with how we're passing
> > the VacuumParams pointer.
> >
> > The call flow is
> > ExecVacuum -> vacuum -> vacuum_rel
> >
> > The initial VaccumParams pointer is set in ExecVacuum
> > In vacuum_rel, this pointer might change because it needs to determine
> > whether to truncate and perform index_cleanup.
>
> Nice find!
>
> My first reaction is to wonder whether we should 1) also make a similar
> change to vacuum() for some future-proofing or 2) just teach vacuum_rel()
> to make a local copy of the parameters that it can scribble on. In the
> latter case, we might want to assert that the parameters don't change after
> calls to vacuum() and vacuum_rel() to prevent this problem from recurring.
> That leads me to think (1) might be the better option, although I'm not too
> wild about the subtlety of the fix.
>
> --
> nathan
Attachment | Content-Type | Size |
---|---|---|
vacuum_tables_options_2.patch | application/octet-stream | 19.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-06-18 20:08:00 | Re: minimum Meson version |
Previous Message | Tom Lane | 2025-06-18 18:36:43 | Re: minimum Meson version |