Re: REPACK (ANALYZE) within transaction block segfaults

Hi everyone,

I believe I was replying to the wrong thread earlier.

The issue I was looking into is the crash caused by executing REPACK
(ANALYZE) inside a transaction block.

REPACK (ANALYZE) performs transaction management internally, including
committing and starting a new transaction while processing the relation. It
therefore cannot safely be executed from an existing transaction block.

I have prepared a patch that rejects REPACK (ANALYZE) with
PreventInTransactionBlock(), consistent with the existing restriction
for REPACK
(CONCURRENTLY). I also added a regression test covering execution inside a
transaction block.

The patch applies cleanly to the current tree and passes git diff --check.
Patch attached.

Regards,
Osama Abdul Qader

On Wed, Sep 2, 2026 at 2:17 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:

> Alvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> > 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.
>
> Maybe the question was about the wording - "synonym" might indicate that
> both
> commands execute the same code. Perhaps the comment should rather say that
> REPACK (ANALYZE) is (intended to be) a replacement of VACUUM (FULL,
> ANALYZE).
>
> --
> Antonin Houska
> Web: https://www.cybertec-postgresql.com
>
>
>