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 <[email protected]> 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 > > >
