> On Sep 10, 2026, at 11:21, shihao zhong <zhong950419@gmail.com> wrote:
>
> Hi Alvaro,
>
> > I would prefer to have a way to transmit the effective values from the
> > leader backend to the worker
>
> Done in v2, through the DSM segment the worker already attaches to.
>
> Only lock_timeout and transaction_timeout are passed. A bgworker never
> arms statement_timeout or idle_in_transaction_session_timeout. v1 have
> because it aligns with the autovacuum worker.
>
> One behavior change from v1. v1 turned the timeouts off, so REPACK always
> got through. v2 uses the caller's values instead, so if the caller has a
> lock_timeout of its own, the command can still be cancelled.
>
> The difference is that it is now cancelled by a value the
> caller sees in SHOW and can override with SET, rather than by one coming
> from the owner role that the caller cannot reach at all.
>
> I did consider SerializeGUCState, but that seems too much.
>
> Applies cleanly to master and REL_19_STABLE.
>
> Regards,
> Shihao
> <v2-0001-Pass-the-backend-s-timeout-settings-to-the-REPACK.patch>
Auto-vacuum explicitly overrides all four settable session timeouts (statement_timeout, transaction_timeout,
lock_timeout,and idle_in_transaction_session_timeout) to zero, while this worker only handles the latter two. I
understandthat statement_timeout and idle_in_transaction_session_timeout are probably never armed by this worker, so
functionallythey may not need special handling.
My concern is that the inconsistency might lead to confusion to future readers. Does it make sense to either remove
thosetwo from auto-vacuum worker or set them to repack worker as well?
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
