Hi, On Fri, Aug 21, 2026 at 3:34 PM Masahiko Sawada <[email protected]> wrote: > > I think we need to carefully think about whether we drop all temp > slots at subxact abort and when we do that. > > Also, is calling ReplicationSlotCleanup() (and possibly > ReplicationSlotRelease()) during sub-transaction abort really safe in > the first place? That function could raise errors and we call it out > of transactions elsewhere. > > I'm inclined to think AtEOSubXact_ReplicationSlot() should only > release the slot and not call ReplicationSlotCleanup() at all. That > said, I'm not fully convinced of this either as it might be > inconsistent with top-level error cases in a sense.
Upon thinking about this more, I realize that temporary slot handling in the subxact error callback looks complicated and hard to reason about from the end user's perspective. I checked commit a924c327e27 that introduced temporary slots. It seems like the behavior was kept simple: release at session end or upon error, without classifying whether the error came from slot handling or something else. Subxact errors caught by exception blocks are usually there to continue in the same transaction, not like top-level ERRORs. I think leaving temp slot cleanup out of subxact error handling and slightly modifying the docs seems fine. On whether it is safe to release the slot during subxact abort, that function could raise an error in one rare scenario (a file rename failure). I checked that when an error is thrown while releasing the slot invoked from PostgresMain()'s sigsetjmp handler, it re-enters that handler, and the resulting recursion eventually overflows the stack, causing a PANIC. The subxact abort path gets the same behavior when releasing the slot there. In short, having just the slot release in the subxact path gives the same error behavior, is simple to reason about, and fixes the crash reported in this thread. Thoughts? -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
