Re: REPACK (ANALYZE) within transaction block segfaults

Hi,

Just a quick update on the replication slot invalidation durability issue.

I've moved past the initial reproduction and have been investigating the
underlying behavior. I now have a candidate patch which changes the
invalidation flow so that the invalidated slot state is persisted before
the invalidation is published in shared memory. The slot synchronization
path has been updated accordingly, and I've also added TAP coverage for the
durability scenarios, including injected failures during slot persistence.

I was able to get the relevant regression coverage passing. While running
the broader recovery test suite, I encountered a few failures in existing
TAP tests, particularly around 001_stream_rep.pl and 006_logical_decoding.pl.
I'm currently investigating whether these are related to my changes or are
test-environment/intermittent issues.

I'll continue working through these failures and validating the patch. Once
the remaining test issues are understood and the patch is cleaned up, I
expect to have a revised patch ready soon.

Best regards,
Osama Abdul Qader

On Sat, Aug 29, 2026 at 1:22 AM Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:

> On Fri, Aug 28, 2026 at 09:15:25PM +0200, Antonin Houska wrote:
> > I think there are just two different concepts (for historical reasons?):
> > vacuum_rel() expects no active transaction on entry, while cluster_rel()
> > handles transaction boundaries on its own.
> >
> > Since REPACK (ANALYZE) is effectively VACUUM (FULL, ANALYZE), I'd prefer
> the
> > same behavior, i.e. prohibiting execution both in a transaction block
> and in a
> > function:
>
> This is probably the way to go for v19. As you note, the analogous VACUUM
> command has long ERROR'd, and we could always look into removing this
> restriction in the future. I'd rather do it that way than ship an
> incorrect fix in v19 that will be tougher to back out.
>
> --
> nathan
>
>
>