On 2026-Sep-08, shihao zhong wrote: > It's in the patch already. My first email was sloppy about this. What I > meant was that a timeout or a cancel on the caller's own session still > kills the command, and the patch leaves that alone. statement_timeout > and idle_in_transaction_session_timeout aren't fire in a bgworker > anyway. I only kept them so the block reads the same as autovacuum.
> What bothers me is that the caller can't work around it. A session > level SET doesn't reach the worker. Ahh, that changes the problem framing completely, and I understand your whole point now. I'm not sure what the best solution is though, but I'm not convinced that resetting the timeouts completely is it. I would prefer to have a way to transmit the effective values from the leader backend to the worker: that way, you use a session-level SET and that is also valid in the worker. I guess the question is how to effect such a transmission ... > > Antonin Houska has a patch which would probably benefit from your > > review. https://postgr.es/m/108776.1784105248@localhost > > Thanks for pointing me to Antonin's patch. I don't think it helps here > though. Oh, I didn't intend to suggest that Antonin's patch helps this case, but rather that if you have development gray cells to spare in connection with REPACK, that's a very good place to put them to work. > I do want to look at his work properly, but I'll do that on his > own thread rather than here. Sounds good! -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Investigación es lo que hago cuando no sé lo que estoy haciendo" (Wernher von Braun)
