Feedback-ID: ie3de48e3:Fastmail
Date: Wed, 2 Sep 2026 10:20:20 +0200
From: Alvaro Herrera <alvherre@kurilemu.de>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	Antonin Houska <ah@cybertec.at>, pgsql-hackers@postgresql.org
Subject: Re: REPACK (ANALYZE) within transaction block segfaults
Message-ID: <apfbHj9TkfvlOeJ3@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAHGQGwEezdMUixhJ-N0YO0OFUmh0uPaXRDkds5FS-5dmdwz4Bg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/apfbHj9TkfvlOeJ3%40alvherre.pgsql>
Precedence: bulk

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)