Date: Thu, 27 Aug 2026 14:39:35 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: pgsql-hackers@postgresql.org, alvherre@kurilemu.de
Subject: Re: REPACK (ANALYZE) within transaction block segfaults
Message-ID: <apCSd2NvvEJfBmVu@nathan>
References: <apBCEl4hBHlq0axm@nathan>
 <CAHGQGwEqN80ka_PY__DiPCu+S=h_7KgujnMEU38OU9C1zsGQpA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAHGQGwEqN80ka_PY__DiPCu+S=h_7KgujnMEU38OU9C1zsGQpA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/apCSd2NvvEJfBmVu%40nathan>
Precedence: bulk

On Fri, Aug 28, 2026 at 01:09:59AM +0900, Fujii Masao wrote:
> On Thu, Aug 27, 2026 at 10:56 PM Nathan Bossart
> <nathandbossart@gmail.com> wrote:
>> Presumably we need to handle transaction blocks a bit like how vacuum()
>> does.  Or maybe even prevent REPACK (ANALYZE) within a transaction block.
> 
> I looked into this a bit. I think the problem is not ordinary
> transaction blocks themselves, but non-top-level execution, such as the
> DO block in the reproducer.
> 
> So the attached patch rejects only non-top-level REPACK (ANALYZE)
> commands.

Hm.  Couldn't we do something like the in_outer_xact/use_own_xacts stuff in
vacuum() to get it working instead?

-- 
nathan