| From: | Alvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: REPACK (ANALYZE) within transaction block segfaults |
| Date: | 2026-09-02 08:20:20 |
| Message-ID: | apfbHj9TkfvlOeJ3@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-Sep-02, Fujii Masao wrote:
> + * that's just consistent with VACUUM (FULL, ANALYZE), which is a
> + * synonym for REPACK (ANALYZE).
>
> Is VACUUM (FULL, ANALYZE) really a synonym for REPACK (ANALYZE)?
That's the intent, at least. If there are things that work differently,
I would strive to change them so that they do work the same. However,
some such changes might be too invasive for pg19, but I would still see
about changing those in pg20.
Now, maybe there are things about VACUUM FULL ANALYZE that we don't like
(perhaps, for instance, they exist solely because of even older
backwards compatibility concerns) that we would prefer not to have in
REPACK. I don't know if anything of that sort exists, but if so, I
would propose to seek decisions for each thing individually.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Essentially, you're proposing Kevlar shoes as a solution for the problem
that you want to walk around carrying a loaded gun aimed at your foot.
(Tom Lane)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jehan-Guillaume de Rorthais | 2026-09-02 08:24:15 | Re: Possible Visibility Map corruption in supported branches? |
| Previous Message | Andrei Lepikhov | 2026-09-02 08:19:29 | Re: SUM(int2)/SUM(int4) do not detect overflow of the int8 accumulator |