agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedREPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
15+ messages / 3 participants
[nested] [flat]
* REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-06 22:05 shihao zhong <zhong950419@gmail.com>
0 siblings, 2 replies; 15+ messages in thread
From: shihao zhong @ 2026-09-06 22:05 UTC (permalink / raw)
To: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
HI hackers,
Running two REPACK (CONCURRENTLY) on one database with
ALTER DATABASE ... SET lock_timeout = '5s', the second one fails:
ERROR: canceling statement due to lock timeout
CONTEXT: waiting for ShareLock on transaction 2076
REPACK decoding worker
The worker waits for the first REPACK's XID in the snapshot builder.
It runs in its own session as the table owner, so the database-level
lock_timeout applies to it, and SET lock_timeout = 0 in the REPACK
session does not reach it.
The attached patch turns the settable timeouts off in the worker, as
autovacuum does. statement_timeout and cancel on the REPACK session
still stop the whole command.
Separately, the wait itself means REPACK (CONCURRENTLY) runs are
serialized. A PROC_IN_SAFE_IC-like flag could let the worker skip
other REPACK transactions; I can look into that if there is interest.
Thanks,
Shihao
Attachments:
[application/octet-stream] 0001-Force-timeouts-off-in-the-REPACK-CONCURRENTLY-decodi.patch (2.0K, ../../CAGRkXqTYaBjFvjtjPb1+=sZWvt93=2c472bmM+xdG7w9ZvAydA@mail.gmail.com/3-0001-Force-timeouts-off-in-the-REPACK-CONCURRENTLY-decodi.patch)
download | inline diff:
From 288c7c88cb3f163bd642e3768d9c34eabe22a43b Mon Sep 17 00:00:00 2001
From: Shihao Zhong <zhong950419@gmail.com>
Date: Sat, 5 Sep 2026 17:07:19 -0400
Subject: [PATCH] Force timeouts off in the REPACK (CONCURRENTLY) decoding
worker
The worker connects as the table owner in a new session, so a role- or
database-level lock_timeout applies to it and cancels its wait for older
transactions, and the user running REPACK cannot override it. Turn the
settable timeouts off in the worker, as autovacuum does.
---
src/backend/commands/repack_worker.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index af7e2a94764..bbb45454494 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -26,6 +26,7 @@
#include "storage/ipc.h"
#include "storage/proc.h"
#include "tcop/tcopprot.h"
+#include "utils/guc.h"
#include "utils/memutils.h"
#define PGREPACK_PLUGIN "pgrepack"
@@ -105,6 +106,20 @@ RepackWorkerMain(Datum main_arg)
BackgroundWorkerInitializeConnectionByOid(shared->dbid, shared->roleid,
BGWORKER_BYPASS_ROLELOGINCHECK);
+ /*
+ * Force settable timeouts off, like autovacuum does. We run in a new
+ * session as the table owner, so role- and database-level settings
+ * apply here even though the user running REPACK cannot see or override
+ * them. A lock_timeout would otherwise abort the wait for older
+ * transactions in the snapshot builder, and a transaction_timeout would
+ * abort the whole command.
+ */
+ SetConfigOption("statement_timeout", "0", PGC_SUSET, PGC_S_OVERRIDE);
+ SetConfigOption("transaction_timeout", "0", PGC_SUSET, PGC_S_OVERRIDE);
+ SetConfigOption("lock_timeout", "0", PGC_SUSET, PGC_S_OVERRIDE);
+ SetConfigOption("idle_in_transaction_session_timeout", "0",
+ PGC_SUSET, PGC_S_OVERRIDE);
+
/*
* Transaction is needed to open relation, and it also provides us with a
* resource owner.
--
2.37.1 (Apple Git-137.1)
[application/octet-stream] N1-repro.log (4.3K, ../../CAGRkXqTYaBjFvjtjPb1+=sZWvt93=2c472bmM+xdG7w9ZvAydA@mail.gmail.com/4-N1-repro.log)
download
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-07 08:12 Chao Li <li.evan.chao@gmail.com>
parent: shihao zhong <zhong950419@gmail.com>
1 sibling, 0 replies; 15+ messages in thread
From: Chao Li @ 2026-09-07 08:12 UTC (permalink / raw)
To: shihao zhong <zhong950419@gmail.com>; +Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
> On Sep 7, 2026, at 06:05, shihao zhong <zhong950419@gmail.com> wrote:
>
> HI hackers,
>
> Running two REPACK (CONCURRENTLY) on one database with
> ALTER DATABASE ... SET lock_timeout = '5s', the second one fails:
>
> ERROR: canceling statement due to lock timeout
> CONTEXT: waiting for ShareLock on transaction 2076
> REPACK decoding worker
>
> The worker waits for the first REPACK's XID in the snapshot builder.
> It runs in its own session as the table owner, so the database-level
> lock_timeout applies to it, and SET lock_timeout = 0 in the REPACK
> session does not reach it.
>
> The attached patch turns the settable timeouts off in the worker, as
> autovacuum does. statement_timeout and cancel on the REPACK session
> still stop the whole command.
Seems reasonable to me. As you also mentioned in the code comment, auto-vacuum does the same thing.
>
> Separately, the wait itself means REPACK (CONCURRENTLY) runs are
> serialized. A PROC_IN_SAFE_IC-like flag could let the worker skip
> other REPACK transactions; I can look into that if there is interest.
>
Yeah, I think the PROC_IN_SAFE_IC-like flag is the key point here. Since multiple VACUUM FULL commands on different tables can run in parallel, having REPACK (CONCURRENTLY) operations serialized could make the feature less competitive. In practice, it is quite common to need to repack more than one table, so allowing independent REPACK operations to proceed in parallel seems worthwhile.
> Thanks,
> Shihao
> <0001-Force-timeouts-off-in-the-REPACK-CONCURRENTLY-decodi.patch><N1-repro.log>
The patch itself looks good to me. The PROC_IN_SAFE_IC-like flag enhancement could probably be discussed separately. I imagine that would be a larger feature?
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-08 07:31 Álvaro Herrera <alvherre@kurilemu.de>
parent: shihao zhong <zhong950419@gmail.com>
1 sibling, 1 reply; 15+ messages in thread
From: Álvaro Herrera @ 2026-09-08 07:31 UTC (permalink / raw)
To: shihao zhong <zhong950419@gmail.com>; +Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
On 2026-Sep-06, shihao zhong wrote:
> The worker waits for the first REPACK's XID in the snapshot builder.
> It runs in its own session as the table owner, so the database-level
> lock_timeout applies to it, and SET lock_timeout = 0 in the REPACK
> session does not reach it.
>
> The attached patch turns the settable timeouts off in the worker, as
> autovacuum does. statement_timeout and cancel on the REPACK session
> still stop the whole command.
Hmm, but there's no practical effect here, right? If it doesn't die
because of this particular timeout, it will fail due to some other
timeout. We just don't have an implementation that allows to run two
concurrent REPACK CONCURRENTLY. Will you later suggest to turn off
statement_timeout during REPACK?
> Separately, the wait itself means REPACK (CONCURRENTLY) runs are
> serialized. A PROC_IN_SAFE_IC-like flag could let the worker skip
> other REPACK transactions; I can look into that if there is interest.
Antonin Houska has a patch which would probably benefit from your
review. https://postgr.es/m/108776.1784105248@localhost
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Hay dos momentos en la vida de un hombre en los que no debería
especular: cuando puede permitírselo y cuando no puede" (Mark Twain)
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-09 01:13 shihao zhong <zhong950419@gmail.com>
parent: Álvaro Herrera <alvherre@kurilemu.de>
0 siblings, 1 reply; 15+ messages in thread
From: shihao zhong @ 2026-09-09 01:13 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
> but there's no practical effect here, right? If it doesn't die because
> of this particular timeout, it will fail due to some other timeout.
It's not really about two concurrent REPACKs. The worker waits for
every running XID, so a single ordinary write transaction does it:
ALTER DATABASE postgres SET lock_timeout = '2s';
-- session 1: BEGIN; INSERT INTO other VALUES (1); (left open)
-- session 2: SET lock_timeout = 0; REPACK (CONCURRENTLY) t;
ERROR: canceling statement due to lock timeout
CONTEXT: waiting for ShareLock on transaction 2096
REPACK decoding worker
> would statement_timeout also need to be turned off?
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. ALTER SYSTEM ranks below ALTER
DATABASE, so that doesn't work either. That leaves two options. You can
reset it on the database, but then every session in that database loses
lock_timeout, and it only takes effect for new connections. Or you can
set it on the owner role, but that needs CREATEROLE plus ADMIN on that
role. A DBA who only has MAINTAIN can't do either one. And the first
option means weakening a protection that the running workload depends
on, just to get a maintenance command to start. That seems backwards
for a command whose whole point is to do the job of VACUUM FULL without
disrupting the workload.
> 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. It keeps REPACK from holding an XID, so REPACK stops blocking
other people. But the worker is on the receiving end. It still has to
wait for whatever regular transactions are running, and that is where
the inherited lock_timeout hits it. The transaction in my repro above
is just a plain INSERT.
I went through the set to be sure. The wait itself is in
SnapBuildWaitSnapshot(), and that function is unchanged across all eight
patches. I do want to look at his work properly, but I'll do that on his
own thread rather than here.
Thanks,
Shihao
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-09 11:48 Álvaro Herrera <alvherre@kurilemu.de>
parent: shihao zhong <zhong950419@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Álvaro Herrera @ 2026-09-09 11:48 UTC (permalink / raw)
To: shihao zhong <zhong950419@gmail.com>; +Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
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)
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-10 03:21 shihao zhong <zhong950419@gmail.com>
parent: Álvaro Herrera <alvherre@kurilemu.de>
0 siblings, 1 reply; 15+ messages in thread
From: shihao zhong @ 2026-09-10 03:21 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
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
Attachments:
[application/octet-stream] v2-0001-Pass-the-backend-s-timeout-settings-to-the-REPACK.patch (3.2K, ../../CAGRkXqSdP2cpsnN8TLEuPs+MnRBTKgX3g4Lz0DiSjRTqAeuGXg@mail.gmail.com/3-v2-0001-Pass-the-backend-s-timeout-settings-to-the-REPACK.patch)
download | inline diff:
From ba90643906250dca3c684c2a8f246fcb4a70d864 Mon Sep 17 00:00:00 2001
From: Shihao Zhong <zhong950419@gmail.com>
Date: Sat, 5 Sep 2026 17:07:19 -0400
Subject: [PATCH v2] Pass the backend's timeout settings to the REPACK decoding
worker
The worker connects as the table owner in a new session, so a role- or
database-level lock_timeout applies to it and cancels its wait for older
transactions, and the user running REPACK cannot override it. Pass the
values in effect in the backend through the shared memory segment the
worker already attaches to, so that a session-level SET reaches it too.
---
src/backend/commands/repack.c | 4 ++++
src/backend/commands/repack_worker.c | 13 +++++++++++++
src/include/commands/repack_internal.h | 4 ++++
3 files changed, 21 insertions(+)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index 0533217968e..d4c5ded6485 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -3692,6 +3692,10 @@ start_repack_decoding_worker(Oid relid)
shared->backend_pid = MyProcPid;
shared->backend_proc_number = MyProcNumber;
+ /* Pass our timeouts to the worker. See RepackWorkerMain(). */
+ shared->lock_timeout = LockTimeout;
+ shared->transaction_timeout = TransactionTimeout;
+
mq = shm_mq_create((char *) BUFFERALIGN(shared->error_queue),
REPACK_ERROR_QUEUE_SIZE);
shm_mq_set_receiver(mq, MyProc);
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b4ba9cfc67b..6e46c479b16 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -26,6 +26,7 @@
#include "storage/ipc.h"
#include "storage/proc.h"
#include "tcop/tcopprot.h"
+#include "utils/guc.h"
#include "utils/memutils.h"
#define PGREPACK_PLUGIN "pgrepack"
@@ -66,6 +67,7 @@ RepackWorkerMain(Datum main_arg)
LogicalDecodingContext *decoding_ctx;
SharedFileSet *sfs;
Snapshot snapshot;
+ char buf[32];
am_repack_worker = true;
@@ -111,6 +113,17 @@ RepackWorkerMain(Datum main_arg)
BGWORKER_BYPASS_ALLOWCONN |
BGWORKER_BYPASS_ROLELOGINCHECK);
+ /*
+ * Adopt the backend's timeouts. We run in a new session as the table
+ * owner, so role- and database-level settings would otherwise apply here,
+ * and the user running REPACK could neither see nor override them. These
+ * are the only two settable timeouts a background worker arms.
+ */
+ snprintf(buf, sizeof(buf), "%d", shared->lock_timeout);
+ SetConfigOption("lock_timeout", buf, PGC_SUSET, PGC_S_OVERRIDE);
+ snprintf(buf, sizeof(buf), "%d", shared->transaction_timeout);
+ SetConfigOption("transaction_timeout", buf, PGC_SUSET, PGC_S_OVERRIDE);
+
/*
* Transaction is needed to open relation, and it also provides us with a
* resource owner.
diff --git a/src/include/commands/repack_internal.h b/src/include/commands/repack_internal.h
index 42111aa4ae3..6b4906fd750 100644
--- a/src/include/commands/repack_internal.h
+++ b/src/include/commands/repack_internal.h
@@ -106,6 +106,10 @@ typedef struct DecodingWorkerShared
pid_t backend_pid;
ProcNumber backend_proc_number;
+ /* Timeouts in effect in the backend. See RepackWorkerMain(). */
+ int lock_timeout;
+ int transaction_timeout;
+
/*
* Memory the queue is located in.
*
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-10 06:21 Chao Li <li.evan.chao@gmail.com>
parent: shihao zhong <zhong950419@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Chao Li @ 2026-09-10 06:21 UTC (permalink / raw)
To: shihao zhong <zhong950419@gmail.com>; +Cc: Álvaro Herrera <alvherre@kurilemu.de>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>
> 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 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.
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?
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-11 16:33 Álvaro Herrera <alvherre@kurilemu.de>
parent: Chao Li <li.evan.chao@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Álvaro Herrera @ 2026-09-11 16:33 UTC (permalink / raw)
To: Chao Li <li.evan.chao@gmail.com>; +Cc: shihao zhong <zhong950419@gmail.com>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>
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.
> 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.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-12 02:57 Chao Li <li.evan.chao@gmail.com>
parent: Álvaro Herrera <alvherre@kurilemu.de>
0 siblings, 1 reply; 15+ messages in thread
From: Chao Li @ 2026-09-12 02:57 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: shihao zhong <zhong950419@gmail.com>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>
> 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/
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-12 03:17 Chao Li <li.evan.chao@gmail.com>
parent: Chao Li <li.evan.chao@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Chao Li @ 2026-09-12 03:17 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: shihao zhong <zhong950419@gmail.com>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>
> On Sep 12, 2026, at 10:57, Chao Li <li.evan.chao@gmail.com> wrote:
>
>
>
>> 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?
>
Say, if another worker is added in the future, the author may look at both the autovacuum and repack workers as references, notice that they reset different sets of timeouts, and then have to spend time figuring out which behavior to follow and why.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-12 12:51 shihao zhong <zhong950419@gmail.com>
parent: Chao Li <li.evan.chao@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: shihao zhong @ 2026-09-12 12:51 UTC (permalink / raw)
To: Chao Li <li.evan.chao@gmail.com>; +Cc: Álvaro Herrera <alvherre@kurilemu.de>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Hi Alvaro, Chao,
Attached is v3. The code is the same as v2, with two additions.
1. The comment in RepackWorkerMain() now says why only lock_timeout and
transaction_timeout are passed. lock_timeout is armed by any lock wait,
and transaction_timeout by StartTransaction(). Both can fire in the
worker: the wait for older transactions in the snapshot builder is a
lock wait, and the worker's transaction spans the whole command.
statement_timeout and idle_in_transaction_session_timeout are only
armed by the command loop in PostgresMain(), which a background worker
never runs. I hope that answers Chao's question without touching
autovacuum.
2. A lock_timeout on the table owner role
does not reach the worker, and one set in the REPACK session does.
It fails on unpatched master and passes with 0001.
I expect this to be common in production, since a database- or
role-level lock_timeout is a normal setting. As REPACK (CONCURRENTLY)
is new in PG19, I suggest adding this to the open items and fixing it
before release.
Thanks,
Shihao
Attachments:
[application/octet-stream] v3-0001-Pass-the-backend-s-timeout-settings-to-the-REPACK.patch (3.7K, ../../CAGRkXqS5B3oe305LxByJt3Hh5-fOUU_dRCsR6w9TuyCPXDVz6Q@mail.gmail.com/3-v3-0001-Pass-the-backend-s-timeout-settings-to-the-REPACK.patch)
download | inline diff:
From 0a94c52409be7e48f2b03c4e088e4117a71abbe9 Mon Sep 17 00:00:00 2001
From: Shihao Zhong <zhong950419@gmail.com>
Date: Sat, 12 Sep 2026 08:46:49 -0400
Subject: [PATCH v3 1/2] Pass the backend's timeout settings to the REPACK
decoding worker
The worker connects as the table owner in a new session, so a role- or
database-level lock_timeout applies to it and cancels its wait for older
transactions, and the user running REPACK cannot override it. The same
holds for transaction_timeout, because the worker's transaction spans the
whole command. Pass the values in effect in the backend through the
shared memory segment the worker already attaches to, so that a
session-level SET reaches it too.
---
src/backend/commands/repack.c | 4 ++++
src/backend/commands/repack_worker.c | 19 +++++++++++++++++++
src/include/commands/repack_internal.h | 4 ++++
3 files changed, 27 insertions(+)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index 83168a4e6f3..139efccb1d5 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -3698,6 +3698,10 @@ start_repack_decoding_worker(Oid relid)
shared->backend_pid = MyProcPid;
shared->backend_proc_number = MyProcNumber;
+ /* Pass our timeouts to the worker. See RepackWorkerMain(). */
+ shared->lock_timeout = LockTimeout;
+ shared->transaction_timeout = TransactionTimeout;
+
mq = shm_mq_create((char *) BUFFERALIGN(shared->error_queue),
REPACK_ERROR_QUEUE_SIZE);
shm_mq_set_receiver(mq, MyProc);
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index b4ba9cfc67b..05139429053 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -26,6 +26,7 @@
#include "storage/ipc.h"
#include "storage/proc.h"
#include "tcop/tcopprot.h"
+#include "utils/guc.h"
#include "utils/memutils.h"
#define PGREPACK_PLUGIN "pgrepack"
@@ -66,6 +67,7 @@ RepackWorkerMain(Datum main_arg)
LogicalDecodingContext *decoding_ctx;
SharedFileSet *sfs;
Snapshot snapshot;
+ char buf[32];
am_repack_worker = true;
@@ -111,6 +113,23 @@ RepackWorkerMain(Datum main_arg)
BGWORKER_BYPASS_ALLOWCONN |
BGWORKER_BYPASS_ROLELOGINCHECK);
+ /*
+ * Adopt the backend's timeouts. We run in a new session as the table
+ * owner, so role- and database-level settings would otherwise apply here,
+ * and the user running REPACK could neither see nor override them.
+ *
+ * lock_timeout is armed by any lock wait (the snapshot builder's wait for
+ * older transactions is one), and transaction_timeout by
+ * StartTransaction(); our transaction spans the whole command.
+ * statement_timeout and idle_in_transaction_session_timeout need no
+ * handling: only the command loop in PostgresMain() arms them, and a
+ * background worker never runs it.
+ */
+ snprintf(buf, sizeof(buf), "%d", shared->lock_timeout);
+ SetConfigOption("lock_timeout", buf, PGC_SUSET, PGC_S_OVERRIDE);
+ snprintf(buf, sizeof(buf), "%d", shared->transaction_timeout);
+ SetConfigOption("transaction_timeout", buf, PGC_SUSET, PGC_S_OVERRIDE);
+
/*
* Transaction is needed to open relation, and it also provides us with a
* resource owner.
diff --git a/src/include/commands/repack_internal.h b/src/include/commands/repack_internal.h
index 42111aa4ae3..6b4906fd750 100644
--- a/src/include/commands/repack_internal.h
+++ b/src/include/commands/repack_internal.h
@@ -106,6 +106,10 @@ typedef struct DecodingWorkerShared
pid_t backend_pid;
ProcNumber backend_proc_number;
+ /* Timeouts in effect in the backend. See RepackWorkerMain(). */
+ int lock_timeout;
+ int transaction_timeout;
+
/*
* Memory the queue is located in.
*
--
2.37.1 (Apple Git-137.1)
[application/octet-stream] v3-0002-Add-isolation-test-for-timeouts-in-the-REPACK-dec.patch (4.4K, ../../CAGRkXqS5B3oe305LxByJt3Hh5-fOUU_dRCsR6w9TuyCPXDVz6Q@mail.gmail.com/4-v3-0002-Add-isolation-test-for-timeouts-in-the-REPACK-dec.patch)
download | inline diff:
From db0835a7e080b8552a08f583402f2d1c5472bc28 Mon Sep 17 00:00:00 2001
From: Shihao Zhong <zhong950419@gmail.com>
Date: Sat, 12 Sep 2026 08:46:49 -0400
Subject: [PATCH v3 2/2] Add isolation test for timeouts in the REPACK decoding
worker
The test checks both directions: a lock_timeout set on the table owner
role does not reach the worker, and one set in the REPACK session does.
---
src/test/modules/injection_points/Makefile | 1 +
.../expected/repack_timeout.out | 18 ++++++++
src/test/modules/injection_points/meson.build | 1 +
.../specs/repack_timeout.spec | 42 +++++++++++++++++++
4 files changed, 62 insertions(+)
create mode 100644 src/test/modules/injection_points/expected/repack_timeout.out
create mode 100644 src/test/modules/injection_points/specs/repack_timeout.spec
diff --git a/src/test/modules/injection_points/Makefile b/src/test/modules/injection_points/Makefile
index 408a35c3c21..e9745d3f275 100644
--- a/src/test/modules/injection_points/Makefile
+++ b/src/test/modules/injection_points/Makefile
@@ -21,6 +21,7 @@ ISOLATION = basic \
repack_decode \
repack_temporal \
repack_temporal_multirange \
+ repack_timeout \
repack_toast \
ri_fastpath_reindex \
ri_fastpath_snapshot \
diff --git a/src/test/modules/injection_points/expected/repack_timeout.out b/src/test/modules/injection_points/expected/repack_timeout.out
new file mode 100644
index 00000000000..6a4d3d0a915
--- /dev/null
+++ b/src/test/modules/injection_points/expected/repack_timeout.out
@@ -0,0 +1,18 @@
+Parsed test spec with 2 sessions
+
+starting permutation: s1_begin s2_repack s1_sleep s1_commit s1_begin s2_lto s2_repack
+step s1_begin: BEGIN; INSERT INTO repack_timeout_other VALUES (1);
+step s2_repack: REPACK (CONCURRENTLY) repack_timeout_tab; <waiting ...>
+step s1_sleep: SELECT pg_sleep(0.5);
+pg_sleep
+--------
+
+(1 row)
+
+step s1_commit: COMMIT;
+step s2_repack: <... completed>
+step s1_begin: BEGIN; INSERT INTO repack_timeout_other VALUES (1);
+step s2_lto: SET lock_timeout = '100ms';
+step s2_repack: REPACK (CONCURRENTLY) repack_timeout_tab; <waiting ...>
+step s2_repack: <... completed>
+ERROR: canceling statement due to lock timeout
diff --git a/src/test/modules/injection_points/meson.build b/src/test/modules/injection_points/meson.build
index a7b40e084f6..1b530a9cfc6 100644
--- a/src/test/modules/injection_points/meson.build
+++ b/src/test/modules/injection_points/meson.build
@@ -50,6 +50,7 @@ tests += {
'repack_decode',
'repack_temporal',
'repack_temporal_multirange',
+ 'repack_timeout',
'repack_toast',
'ri_fastpath_reindex',
'ri_fastpath_snapshot',
diff --git a/src/test/modules/injection_points/specs/repack_timeout.spec b/src/test/modules/injection_points/specs/repack_timeout.spec
new file mode 100644
index 00000000000..2842be0ad0a
--- /dev/null
+++ b/src/test/modules/injection_points/specs/repack_timeout.spec
@@ -0,0 +1,42 @@
+# Timeouts in the REPACK (CONCURRENTLY) decoding worker.
+#
+# The worker connects as the table owner in a new session, so the timeouts
+# set for that role (or for the database) would apply to it while it waits
+# for older transactions to finish. Instead, the worker adopts the values in
+# effect in the session running REPACK, so that the user can control them
+# with SET.
+
+setup
+{
+ CREATE ROLE regress_repack_timeout;
+ ALTER ROLE regress_repack_timeout SET lock_timeout = '100ms';
+
+ CREATE TABLE repack_timeout_tab (a int PRIMARY KEY);
+ INSERT INTO repack_timeout_tab VALUES (1), (2);
+ ALTER TABLE repack_timeout_tab OWNER TO regress_repack_timeout;
+
+ CREATE TABLE repack_timeout_other (a int);
+}
+
+teardown
+{
+ DROP TABLE repack_timeout_tab, repack_timeout_other;
+ DROP ROLE regress_repack_timeout;
+}
+
+# Hold an XID that the decoding worker has to wait for.
+session s1
+step s1_begin { BEGIN; INSERT INTO repack_timeout_other VALUES (1); }
+# Keep the worker waiting for longer than the role's lock_timeout.
+step s1_sleep { SELECT pg_sleep(0.5); }
+step s1_commit { COMMIT; }
+teardown { ABORT; }
+
+session s2
+step s2_lto { SET lock_timeout = '100ms'; }
+step s2_repack { REPACK (CONCURRENTLY) repack_timeout_tab; }
+
+# The role-level lock_timeout does not reach the worker: REPACK waits until
+# s1 finishes. With lock_timeout set in the REPACK session, the worker's
+# wait is cancelled by that value.
+permutation s1_begin s2_repack s1_sleep s1_commit s1_begin s2_lto s2_repack(*)
--
2.37.1 (Apple Git-137.1)
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-17 10:56 Álvaro Herrera <alvherre@kurilemu.de>
parent: shihao zhong <zhong950419@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Álvaro Herrera @ 2026-09-17 10:56 UTC (permalink / raw)
To: shihao zhong <zhong950419@gmail.com>; +Cc: Chao Li <li.evan.chao@gmail.com>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>
On 2026-Sep-12, shihao zhong wrote:
> 1. The comment in RepackWorkerMain() now says why only lock_timeout and
> transaction_timeout are passed. lock_timeout is armed by any lock wait,
> and transaction_timeout by StartTransaction(). Both can fire in the
> worker: the wait for older transactions in the snapshot builder is a
> lock wait, and the worker's transaction spans the whole command.
> statement_timeout and idle_in_transaction_session_timeout are only
> armed by the command loop in PostgresMain(), which a background worker
> never runs. I hope that answers Chao's question without touching
> autovacuum.
Thanks. I pushed the patch, but didn't keep the detailed comment. I
don't think we need to explain the details of how these timeouts work in
this comment, and it may be easy for the comment to become outdated.
I added the word "relevant" to the comment, to try and satisfy Chao's
concern: a reader of this code trying to add a new worker will have to
figure out what does "relevant" mean in whatever case they're trying to
implement :-)
> 2. A lock_timeout on the table owner role does not reach the worker,
> and one set in the REPACK session does. It fails on unpatched master
> and passes with 0001.
Did you mean to reference the proposed new test in this paragraph? I
think so, but the text says something else. (I don't really know what
the text tries to convey). Anyway, I didn't push this test either,
because I think it's likely to fail randomly on slow buildfarm machines,
so we would have to adjust the timeouts, and that becomes a whack-a-mole
game that I'm not very interested in playing at this point.
Thanks for the report and fix,
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Before you were born your parents weren't as boring as they are now. They
got that way paying your bills, cleaning up your room and listening to you
tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-18 00:29 shihao zhong <zhong950419@gmail.com>
parent: Álvaro Herrera <alvherre@kurilemu.de>
0 siblings, 1 reply; 15+ messages in thread
From: shihao zhong @ 2026-09-18 00:29 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Chao Li <li.evan.chao@gmail.com>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Hi Alvaro,
> Thanks. I pushed the patch, but didn't keep the detailed comment.
Thanks for pushing it, and for the backpatch to 19.
> Did you mean to reference the proposed new test in this paragraph?
Yes, sorry, that paragraph was about the test in 0002. You are right
that it is timing sensitive. It only caught the bug after I added a
pg_sleep before the COMMIT, so it would be fragile on slow machine.
Leaving it out is fine.
Thanks,
Shihao
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-18 00:52 shihao zhong <zhong950419@gmail.com>
parent: shihao zhong <zhong950419@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: shihao zhong @ 2026-09-18 00:52 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Chao Li <li.evan.chao@gmail.com>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Hi Alvaro,
I looked at the other settings to see if any of them has the same
problem. I found temp_file_limit, the worker uses it for its decoding
files. 003 fixes it the same way as the timeouts.
Thanks,
Shihao
Attachments:
[application/octet-stream] 0003-Have-the-REPACK-decoding-worker-use-temp_file_lim.patch (3.1K, ../../CAGRkXqQmg=wOT_4zK7cu9b34Wp_hcG5TD_WeD4mrVGLQ1Ld-1w@mail.gmail.com/3-0003-Have-the-REPACK-decoding-worker-use-temp_file_lim.patch)
download | inline diff:
From 1a20eb5ef04e4368d1a5acfc6642accfea2f5945 Mon Sep 17 00:00:00 2001
From: Shihao <zhong950419@gmail.com>
Date: Thu, 17 Sep 2026 20:44:18 -0400
Subject: [PATCH v1] Have the REPACK decoding worker use temp_file_limit from
the steering backend
The worker runs as the table owner, so a role or database level
temp_file_limit of the owner applies to its decoding files. Pass the
value from the steering backend, as a62ff0829d6 did for the timeouts.
Author: Shihao Zhong <zhong950419@gmail.com>
Discussion: https://postgr.es/m/CAGRkXqTYaBjFvjtjPb1+=sZWvt93=2c472bmM+xdG7w9ZvAydA@mail.gmail.com
---
src/backend/commands/repack.c | 4 +++-
src/backend/commands/repack_worker.c | 4 +++-
src/include/commands/repack_internal.h | 3 ++-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c
index 759be53d6b8..82f8fc201e0 100644
--- a/src/backend/commands/repack.c
+++ b/src/backend/commands/repack.c
@@ -67,6 +67,7 @@
#include "pgstat.h"
#include "replication/logicalrelation.h"
#include "storage/bufmgr.h"
+#include "storage/fd.h"
#include "storage/ipc.h"
#include "storage/lmgr.h"
#include "storage/predicate.h"
@@ -3772,9 +3773,10 @@ start_repack_decoding_worker(Oid relid)
shared->backend_pid = MyProcPid;
shared->backend_proc_number = MyProcNumber;
- /* Transmit our timeouts to the worker too */
+ /* Transmit our relevant settings to the worker too */
shared->lock_timeout = LockTimeout;
shared->transaction_timeout = TransactionTimeout;
+ shared->temp_file_limit = temp_file_limit;
mq = shm_mq_create((char *) BUFFERALIGN(shared->error_queue),
REPACK_ERROR_QUEUE_SIZE);
diff --git a/src/backend/commands/repack_worker.c b/src/backend/commands/repack_worker.c
index 690863c6411..b206522da6d 100644
--- a/src/backend/commands/repack_worker.c
+++ b/src/backend/commands/repack_worker.c
@@ -111,11 +111,13 @@ RepackWorkerMain(Datum main_arg)
BGWORKER_BYPASS_ALLOWCONN |
BGWORKER_BYPASS_ROLELOGINCHECK);
- /* Adopt the steering backend's relevant timeouts. */
+ /* Adopt the steering backend's relevant settings. */
snprintf(buf, sizeof(buf), "%d", shared->lock_timeout);
SetConfigOption("lock_timeout", buf, PGC_SUSET, PGC_S_OVERRIDE);
snprintf(buf, sizeof(buf), "%d", shared->transaction_timeout);
SetConfigOption("transaction_timeout", buf, PGC_SUSET, PGC_S_OVERRIDE);
+ snprintf(buf, sizeof(buf), "%d", shared->temp_file_limit);
+ SetConfigOption("temp_file_limit", buf, PGC_SUSET, PGC_S_OVERRIDE);
/*
* Transaction is needed to open relation, and it also provides us with a
diff --git a/src/include/commands/repack_internal.h b/src/include/commands/repack_internal.h
index ec6e31d77f2..9592b80f68e 100644
--- a/src/include/commands/repack_internal.h
+++ b/src/include/commands/repack_internal.h
@@ -95,9 +95,10 @@ typedef struct DecodingWorkerShared
/* Role to connect as. */
Oid roleid;
- /* Timeouts to use in the worker */
+ /* Settings to use in the worker */
int lock_timeout;
int transaction_timeout;
+ int temp_file_limit;
/* Relation from which data changes to decode. */
Oid relid;
--
2.37.1 (Apple Git-137.1)
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
@ 2026-09-24 02:52 shihao zhong <zhong950419@gmail.com>
parent: shihao zhong <zhong950419@gmail.com>
0 siblings, 0 replies; 15+ messages in thread
From: shihao zhong @ 2026-09-24 02:52 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Chao Li <li.evan.chao@gmail.com>; pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Hi Alvaro,
A gentle ping on 003. I should have shown the symptom last time. If the
table owner has a role level temp_file_limit, REPACK (CONCURRENTLY) fails
under concurrent updates, even when a superuser runs it:
ERROR: temporary file size exceeds "temp_file_limit" (64kB)
CONTEXT: slot "pg_repack_11897", output plugin "pgrepack", in the change
callback, associated LSN 0/20A7BF00
That was ALTER ROLE owner SET temp_file_limit = '64kB' and 20k updates
during the REPACK. The caller can't override it, same as the timeouts
before a62ff0829d6. The patch still applies cleanly on master.
Should we also add that to the open item list?
Thanks,
Shihao
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2026-09-24 02:52 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-06 22:05 REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout shihao zhong <zhong950419@gmail.com>
2026-09-07 08:12 ` Chao Li <li.evan.chao@gmail.com>
2026-09-08 07:31 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-09-09 01:13 ` shihao zhong <zhong950419@gmail.com>
2026-09-09 11:48 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-09-10 03:21 ` shihao zhong <zhong950419@gmail.com>
2026-09-10 06:21 ` Chao Li <li.evan.chao@gmail.com>
2026-09-11 16:33 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-09-12 02:57 ` Chao Li <li.evan.chao@gmail.com>
2026-09-12 03:17 ` Chao Li <li.evan.chao@gmail.com>
2026-09-12 12:51 ` shihao zhong <zhong950419@gmail.com>
2026-09-17 10:56 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-09-18 00:29 ` shihao zhong <zhong950419@gmail.com>
2026-09-18 00:52 ` shihao zhong <zhong950419@gmail.com>
2026-09-24 02:52 ` shihao zhong <zhong950419@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox