Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\))
Subject: Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: <aqQslOwhDkbNYerk@alvherre.pgsql>
Date: Sat, 12 Sep 2026 10:57:01 +0800
Cc: shihao zhong <zhong950419@gmail.com>,
 pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E65FC0AC-28D4-4EEF-9A7D-D5FECAC9CFC8@gmail.com>
References: <aqQslOwhDkbNYerk@alvherre.pgsql>
To: =?utf-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>
Archived-At: 
 <https://www.postgresql.org/message-id/E65FC0AC-28D4-4EEF-9A7D-D5FECAC9CFC8%40gmail.com>
Precedence: bulk


> On Sep 12, 2026, at 00:33, =C3=81lvaro Herrera <alvherre@kurilemu.de> =
wrote:
>=20
> On 2026-Sep-10, Chao Li wrote:
>=20
>>> On Sep 10, 2026, at 11:21, shihao zhong <zhong950419@gmail.com> =
wrote:
>=20
>>> Done in v2, through the DSM segment the worker already attaches to.
>=20
> I think this is pretty reasonable.
>=20
>> 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 understand that statement_timeout and
>> idle_in_transaction_session_timeout are probably never armed by this
>> worker, so functionally they may not need special handling.
>=20
> Hmm, but REPACK is not autovacuum; it's quite different in fact, in =
that
> REPACK is intended to always be invoked manually, while autovacuum =
runs
> on its own.  On the other hand, because REPACK refuses to run in a
> transaction block, transaction_timeout and
> idle_in_transaction_session_timeout don't really apply, so I'm not
> seeing the potential for problems.
>=20

Yeah, I fully understood the difference. My concern was only about the =
inconsistency.

>> My concern is that the inconsistency might lead to confusion to =
future
>> readers. Does it make sense to either remove those two from
>> auto-vacuum worker or set them to repack worker as well?
>=20
> I decidedly don't want to touch autovacuum.  Although I'm not sure I =
see
> the reason why the transaction-based timeouts are relevant for
> autovacuum.
>=20

That was actually my concern. The fact that this raised the question of =
why autovacuum resets those timeouts suggests that the inconsistency can =
be confusing to readers.

I agree we don't need to touch autovacuum in this patch. Does it make =
sense to remove those unnecessary timeout resets from autovacuum by a =
separate patch?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/