pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedFrom: Chao Li <li.evan.chao@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: shihao zhong <zhong950419@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
Date: Sat, 12 Sep 2026 10:57:01 +0800
Message-ID: <E65FC0AC-28D4-4EEF-9A7D-D5FECAC9CFC8@gmail.com> (raw)
In-Reply-To: <aqQslOwhDkbNYerk@alvherre.pgsql>
References: <aqQslOwhDkbNYerk@alvherre.pgsql>
> On Sep 12, 2026, at 00:33, Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
> On 2026-Sep-10, Chao Li wrote:
>
>>> On Sep 10, 2026, at 11:21, shihao zhong <zhong950419@gmail.com> wrote:
>
>>> Done in v2, through the DSM segment the worker already attaches to.
>
> I think this is pretty reasonable.
>
>> 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.
>
> 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.
>
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?
>
> 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.
>
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/
view thread (15+ messages) latest in thread
Message-ID: <E65FC0AC-28D4-4EEF-9A7D-D5FECAC9CFC8@gmail.com>
Permalink: ../E65FC0AC-28D4-4EEF-9A7D-D5FECAC9CFC8@gmail.com/
Also on: postgresql.org/message-id/E65FC0AC-28D4-4EEF-9A7D-D5FECAC9CFC8@gmail.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: li.evan.chao@gmail.com, alvherre@kurilemu.de, zhong950419@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
In-Reply-To: <E65FC0AC-28D4-4EEF-9A7D-D5FECAC9CFC8@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox