Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout

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)