repack_swap failed due to lock timeout because of autovacuum to prevent wraparound

[vdegtyarevtv]

Hi! We are using repack version 1.5.2
pg_repack | 1.5.2 | public | Reorganize tables in PostgreSQL databases with minimal locks
We faced with issue, that repack failed

DEBUG: ---- swap ----
ERROR: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: SELECT repack.repack_swap($1)
DEBUG: Disconnecting worker 0.
DEBUG: Disconnecting worker 1.
DEBUG: Disconnecting worker 2.
DEBUG: Disconnecting worker 3.

I checked the postgres log and found this

2025-10-12 04:05:27 UTC [postgres] [20154]: [1] LOG:  process 20154 still waiting for AccessExclusiveLock on relation 216037684 of database 216037410 after 1000.030 ms
2025-10-12 04:05:27 UTC [postgres] [20154]: [2] DETAIL:  Process holding the lock: 24977. Wait queue: 20154.
2025-10-12 04:05:27 UTC [postgres] [20154]: [3] STATEMENT:  SELECT repack.repack_swap($1)

The process with pid 20154 is autovacuum to prevent wraparound

-[ RECORD 1 ]----+-----------------------------------------------------------------------
pid              | 24977
query            | autovacuum: VACUUM pg_toast.pg_toast_216037680 (to prevent wraparound)

So, here's how I see the situation:

1. Repack was trying to execute the repack_swap function, but it did so without a minimal lock timeout in the loop. Why is that?
2. While Repack had the exclusive lock on the table, it locked all queries on it.
3. After 45 seconds, the repack_swap operation failed due to a lock timeout.

2025-10-12 04:06:11 UTC [postgres] [20154]: [4] ERROR:  canceling statement due to lock timeout
2025-10-12 04:06:11 UTC [postgres] [20154]: [5] STATEMENT:  SELECT repack.repack_swap($1)

That's lock timeout from our side

db=# show lock_timeout
 lock_timeout
--------------
 45s
(1 row)

So, if that was the case of the simple autovacuum ,not to prevent wraparound, it would be cancelled by Postgres (because repack_swap was trying to hold the lock for a long time), but that doesn't work with autovacuum to prevent wraparound. At that stage of the repack execution, I expected the repack to execute repack_swap in a loop with a lock_timeout of 1 second (or less), but it simply stuck for a long time and locked the entire table. I think that, at that stage, repack could have terminated the autovacuum process without any problems because the source table would be dropped. Maybe we need to add it in the repack_swap function?

[za-arthur]

At the stage of calling repack_swap() pg_repack already acquired ACCESS EXCLUSIVE lock on the target table:

pg_repack/bin/pg_repack.c

Line 1622 in 78bc373

if (!(lock_exclusive(conn2, utoa(table->target_oid, buffer),

therefore having a loop inside repack_swap() to lock additional tables will just expand lock time of the target table.

I think that, at that stage, repack could have terminated the autovacuum process without any problems because the source table would be dropped.

AFAIK you need to be a superuser to be able to terminate the autovacuum process for postgres < 18.

[vdegtyarevtv]

@za-arthur thanks for your reply!

therefore having a loop inside repack_swap() to lock additional tables will just expand lock time of the target table.

I agree with you, I missed lock_exclusive execution before repack_swap

AFAIK you need to be a superuser to be able to terminate the autovacuum process for postgres < 18.

I was almost sure that pg_repack should be started by superuser only

Now I'm trying to understand the code and it's hard for me)
Here is the full output of the command that failed, with some data obscured. I think this will be useful for you.

root@postgresql-host:/# cat /var/log/repack/repack.log
DEBUG: No workers to disconnect.
DEBUG: In setup_workers(), target num_workers = 4
NOTICE: Setting up workers.conns
DEBUG: Setting up worker conn 0
DEBUG: Setting up worker conn 1
DEBUG: Setting up worker conn 2
DEBUG: Setting up worker conn 3
INFO: repacking table "public.table"
DEBUG: ---- repack_one_table ----
DEBUG: target_name       : public.table
DEBUG: target_oid        : 216037680
DEBUG: target_toast      : 216037684
DEBUG: target_tidx       : 216037685
DEBUG: pkid              : 682010243
DEBUG: ckid              : 0
DEBUG: create_pktype     : SELECT repack.create_index_type(682010243,216037680)
DEBUG: create_log        : SELECT repack.create_log_table(216037680)
DEBUG: create_trigger    : CREATE TRIGGER repack_trigger AFTER INSERT OR DELETE OR UPDATE ON public.table FOR EACH ROW EXECUTE PROCEDURE repack.repack_trigger('id')
DEBUG: enable_trigger    : ALTER TABLE public.table ENABLE ALWAYS TRIGGER repack_trigger
DEBUG: create_table      : SELECT repack.create_table($1, $2)
DEBUG: dest_tablespace   : pg_default
DEBUG: copy_data         : INSERT INTO repack.table_216037680 SELECT many_columns FROM ONLY public.table
DEBUG: alter_col_storage : ALTER TABLE repack.table_216037680 ALTER column_m SET STORAGE EXTERNAL, ALTER column_n SET STORAGE EXTERNAL
DEBUG: drop_columns      : (skipped)
DEBUG: delete_log        : DELETE FROM repack.log_216037680
DEBUG: lock_table        : LOCK TABLE public.table IN ACCESS EXCLUSIVE MODE
DEBUG: sql_peek          : SELECT * FROM repack.log_216037680 ORDER BY id LIMIT $1
DEBUG: sql_insert        : INSERT INTO repack.table_216037680 VALUES ($1.*)
DEBUG: sql_delete        : DELETE FROM repack.table_216037680 WHERE (id) = ($1.id)
DEBUG: sql_update        : UPDATE repack.table_216037680 SET (many_columns) = ($2many_columns) WHERE (id) = ($1.id)
DEBUG: sql_pop           : DELETE FROM repack.log_216037680 WHERE id IN (
DEBUG: ---- setup ----
DEBUG: index[0].target_oid      : 681946598
DEBUG: index[0].create_index    : CREATE INDEX index_681946598 ON repack.table_216037680 USING btree (columns)
DEBUG: index[1].target_oid      : 682010243
DEBUG: index[1].create_index    : CREATE UNIQUE INDEX index_682010243 ON repack.table_216037680 USING btree (column)
DEBUG: index[2].target_oid      : 682039598
DEBUG: index[2].create_index    : CREATE UNIQUE INDEX index_682039598 ON repack.table_216037680 USING btree (column)
DEBUG: LOCK TABLE public.table IN ACCESS SHARE MODE
DEBUG: No competing DDL to cancel.
DEBUG: Waiting on ACCESS SHARE lock...
DEBUG: ---- copy tuples ----
DEBUG: No competing DDL to cancel.
DEBUG: ---- create indexes ----
DEBUG: Have 3 indexes and num_workers=3
DEBUG: set up index_jobs [0]
DEBUG: target_oid   : 681946598
DEBUG: create_index : CREATE INDEX index_681946598 ON repack.table_216037680 USING btree (columns)
LOG: Initial worker 0 to build index: CREATE INDEX index_681946598 ON repack.table_216037680 USING btree (columns)
DEBUG: set up index_jobs [1]
DEBUG: target_oid   : 682010243
DEBUG: create_index : CREATE UNIQUE INDEX index_682010243 ON repack.table_216037680 USING btree (id)
LOG: Initial worker 1 to build index: CREATE UNIQUE INDEX index_682010243 ON repack.table_216037680 USING btree (id)
DEBUG: set up index_jobs [2]
DEBUG: target_oid   : 682039598
DEBUG: create_index : CREATE UNIQUE INDEX index_682039598 ON repack.table_216037680 USING btree (columns)
LOG: Initial worker 2 to build index: CREATE UNIQUE INDEX index_682039598 ON repack.table_216037680 USING btree (columns)
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 0
DEBUG: polling 3 active workers
DEBUG: Poll returned: 1
LOG: Command finished in worker 1: CREATE UNIQUE INDEX index_682010243 ON repack.table_216037680 USING btree (id)
DEBUG: polling 2 active workers
DEBUG: Poll returned: 1
LOG: Command finished in worker 0: CREATE INDEX index_681946598 ON repack.table_216037680 USING btree (columns)
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 0
DEBUG: polling 1 active workers
DEBUG: Poll returned: 1
LOG: Command finished in worker 2: CREATE UNIQUE INDEX index_682039598 ON repack.table_216037680 USING btree (columns)
DEBUG: ---- swap ----
ERROR: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: SELECT repack.repack_swap($1)
DEBUG: Disconnecting worker 0.
DEBUG: Disconnecting worker 1.
DEBUG: Disconnecting worker 2.
DEBUG: Disconnecting worker 3.

I checked the code of lock_exclusive function and probably find the problem. The function is trying to obtain the lock on the table, but we had the autovacuum to prevent wraparound on toast of that table. I tried to reproduced that.

database=# alter table_name table SET (toast.autovacuum_freeze_max_age = 100000); alter table table_name SET (toast.autovacuum_freeze_min_age=0);alter table table_name SET (toast.autovacuum_freeze_table_age=0);
ALTER TABLE
ALTER TABLE
ALTER TABLE

after that autovacuum to prevent wraparound started running

-[ RECORD 1 ]-----------+-----------------------------------------------------------------------
query_age               | 00:01:03.323122
transaction_age         | 00:01:03.323127
since_last_state_change | 00:01:03.323127
datid                   | 216037410
datname                 | database
pid                     | 3269752
leader_pid              |
usesysid                |
usename                 |
application_name        |
client_addr             |
client_hostname         |
client_port             |
backend_start           | 2025-10-14 05:30:44.958635+00
xact_start              | 2025-10-14 05:30:44.960405+00
query_start             | 2025-10-14 05:30:44.960405+00
state_change            | 2025-10-14 05:30:44.960405+00
wait_event_type         | IO
wait_event              | DataFileRead
state                   | active
backend_xid             |
backend_xmin            | 4057309608
query_id                |
query                   | autovacuum: VACUUM pg_toast.pg_toast_216037680 (to prevent wraparound)
backend_type            | autovacuum worker

and after that i tried to do the same commands as in lock_exclusive function

database=# BEGIN ISOLATION LEVEL READ COMMITTED;
BEGIN
database=*# SAVEPOINT repack_sp1;
SAVEPOINT
database=*# SET LOCAL lock_timeout = 100;;
SET
database=*# LOCK TABLE table_name IN ACCESS EXCLUSIVE MODE;
LOCK TABLE
database=*#

Lock acquired successfully!
However, the repack should then execute the repack_swap function. I am not sure how to reproduce the execution of this function quickly, but I am almost certain that it will be blocked by the autovacuum process. Therefore, I believe you were thinking that the lock_exclusive execution would allow the repack_swap to run without any locks, but this is not the case.
Do you have any thoughts on this? Perhaps pg_repack should also execute the lock_exclusive command on the toast table?

[za-arthur]

I was almost sure that pg_repack should be started by superuser only

It was changed recently and now it can by run by a table's owner:
#431

I suppose that in your example pg_repack tries to acquire ACCESS EXCLUSIVE lock when it tried to rename the toast relations:

pg_repack/lib/repack.c

Line 984 in 78bc373

RENAME_REL(reltoastrelid2, name);

Do you have any thoughts on this? Perhaps pg_repack should also execute the lock_exclusive command on the toast table?

Having a separate lock_exclusive() on a toast table will just expand the exclusive lock on the target table I think. There is a long lived transaction opened by conn2 and you cannot just rollback that transaction, which holds now ACCESS EXCLUSIVE on the target table but not on the toast table yet. The solution might be to take ACCESS EXCLUSIVE lock on all relevant tables in one SAVEPOINT and one loop, that would require adding new function. Or maybe conn2 could take SHARE UPDATE EXCLUSIVE lock on the toast table here in advance:

pg_repack/bin/pg_repack.c

Line 1418 in 78bc373

printfStringInfo(&sql, "LOCK TABLE %s IN SHARE UPDATE EXCLUSIVE MODE",

But in general it might be not a good idea to start pg_repack when your table is going be hit by anti-wraparound autovacuum.

[vdegtyarevtv]

The solution might be to take ACCESS EXCLUSIVE lock on all relevant tables in one SAVEPOINT and one loop, that would require adding new function

Yep, I mean it, but not one more function for only toast table

But in general it might be not a good idea to start pg_repack when your table is going be hit by anti-wraparound autovacuum.

You are partially right. We have an issue now, that our table so large, that autovacuum to prevent wraparound running for 3 day and after the finish of execution started again, because of high load on the table. Only on weekend can happened the default autovacuum, but the last time was anti-wraparound on weekends too. So the only solve of this problems is to repack table and do it every 2 weeks (as we did earlier).
Thanks for your help. We made the decision now to kill anti-wraparound autovacuum in the loop on the stage of log table applying.

[vdegtyarevtv]

@za-arthur Hi again.
We encountered another issue that was somewhat related to the previous one. As I mentioned before, the automatic vacuum process to prevent wraparound was blocking the swap operation. Therefore, we decided to disable the automatic vacuum execution on the target table by setting the autovacuum_naptime parameter to max_value at the moment when the log table contains less than 10% of the total number of records while the repack_apply process was running

2025-11-08 12:50:45 UTC [postgres] [1076]: [1] LOG:  statement: ALTER SYSTEM SET autovacuum_naptime=2147483
2025-11-08 12:50:50 UTC [] [444]: [91] LOG:  received SIGHUP, reloading configuration files
2025-11-08 12:50:50 UTC [] [444]: [93] LOG:  parameter "autovacuum_naptime" changed to "2147483"

After that, we killed the autovacuum process on the target table. We tried to kill it on the heap and toast parts, but found it only on the toast part.

2025-11-08 12:51:03 UTC [] [2171]: [1] FATAL:  terminating autovacuum process due to administrator command
2025-11-08 12:51:03 UTC [] [2171]: [2] CONTEXT:  while vacuuming block 800383515 of relation "pg_toast.pg_toast_216037680"

And after that, the vacuum on the target didn't start until the swap execution. However, there was still a problem with the swap. The first issue was that the vacuum was running on the toast part of the repacked table in the repack scheme. I noticed that you disabled autovacuum for the log table, but I was wondering if it should also be disabled for the repack.table_ table. So we got a lock.

2025-11-08 13:20:47 UTC [postgres] [36414]: [2] LOG:  process 36414 still waiting for AccessExclusiveLock on relation 2330955083 of database 216037410 after 1000.031 ms
2025-11-08 13:20:47 UTC [postgres] [36414]: [3] DETAIL:  Process holding the lock: 19135. Wait queue: 36414.
2025-11-08 13:20:47 UTC [postgres] [36414]: [4] STATEMENT:  SELECT repack.repack_swap($1)

But that was not a critical problem, as it was not an anti-wraparound autovacuum and it was killed quickly.

2025-11-08 13:20:47 UTC [] [19135]: [1] ERROR:  canceling autovacuum task
2025-11-08 13:20:47 UTC [] [19135]: [2] CONTEXT:  while scanning block 227462655 of relation "pg_toast.pg_toast_2330955080"
        automatic vacuum of table "my_db.pg_toast.pg_toast_2330955080"
2025-11-08 13:20:47 UTC [postgres] [36414]: [5] LOG:  process 36414 acquired AccessExclusiveLock on relation 2330955083 of database 216037410 after 1000.796 ms
2025-11-08 13:20:47 UTC [postgres] [36414]: [6] STATEMENT:  SELECT repack.repack_swap($1)

However, if the autovacuum is disabled during the creation of the table and the repack_swap is enabled afterwards, this issue will not occur. After that, some strange things started happening and some of them were not related to the repack execution. However, I want to mention them as well. As you can see from the above, the repack_swap successfully obtained the lock and the function successfully completed. Then, the repack.repack_drop was started. In the repack log

DEBUG: ---- swap ----
DEBUG: ---- drop ----
DEBUG: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
ERROR: query failed: ERROR:  canceling statement due to lock timeout
CONTEXT:  SQL statement "DROP TABLE IF EXISTS repack.table_216037680 CASCADE"
DETAIL: query was: SELECT repack.repack_drop($1, $2)

As you can see above, the function execution failed due to a lock timeout. In our case, it was 45 seconds. This happened because of the autovacuum process

2025-11-08 13:20:48 UTC [postgres] [36413]: [982] LOG:  process 36413 still waiting for AccessExclusiveLock on relation 1827642466 of database 216037410 after 1000.027 ms
2025-11-08 13:20:48 UTC [postgres] [36413]: [983] DETAIL:  Process holding the lock: 19135. Wait queue: 36413.
2025-11-08 13:20:48 UTC [postgres] [36413]: [984] CONTEXT:  SQL statement "DROP TABLE IF EXISTS repack.table_216037680 CASCADE"
2025-11-08 13:20:48 UTC [postgres] [36413]: [985] STATEMENT:  SELECT repack.repack_drop($1, $2)

The 19135 pid is

SELECT
    a.pid,
    a.backend_start,
    a.xact_start,
    a.query_start,
    p.datname,
    p.relid::regclass AS table_name,
    p.phase,
    round(100 * p.heap_blks_scanned / NULLIF(p.heap_blks_total, 0), 2) AS heap_scan_pct,
    round(100 * p.heap_blks_vacuumed / NULLIF(p.heap_blks_total, 0), 2) AS heap_vacuum_pct,
    p.heap_blks_scanned,
    p.heap_blks_total,
    p.heap_blks_vacuumed,
    p.index_vacuum_count,
    a.query,
    now() - a.query_start AS running_for
FROM pg_stat_progress_vacuum p
JOIN pg_stat_activity a ON p.pid = a.pid \gx

-[ RECORD 2 ]------+-----------------------------------------------------------------------
pid                | 19135
backend_start      | 2025-11-08 06:45:23.707208+00
xact_start         | 2025-11-08 13:20:47.515271+00
query_start        | 2025-11-08 13:20:47.515271+00
datname            | my_db
table_name         | pg_toast.pg_toast_2330955080
phase              | scanning heap
heap_scan_pct      | 29.00
heap_vacuum_pct    | 0.00
heap_blks_scanned  | 353012642
heap_blks_total    | 1201988984
heap_blks_vacuumed | 0
index_vacuum_count | 0
query              | autovacuum: VACUUM pg_toast.pg_toast_216037680 (to prevent wraparound)
running_for        | 01:30:28.460263

The first thing I can explain now is why the autovacuum process has started. At that time, autovacuum_naptime was 2147483. I can prove that I changed it 5 minutes after that happened

2025-11-08 13:25:22 UTC [postgres] [33554]: [1] LOG:  statement: ALTER SYSTEM RESET autovacuum_naptime
2025-11-08 13:25:26 UTC [] [444]: [98] LOG:  received SIGHUP, reloading configuration files
2025-11-08 13:25:26 UTC [] [444]: [100] LOG:  parameter "autovacuum_naptime" changed to "1min"

And the second thing I can't explain is why the query from pg_stat_activity shows autovacuum: VACUUM pg_toast.pg_toast_216037680 (to prevent wraparound), but the table name from pg_stat_progress_vacuum is pg_toast.pg_toast_2330955080. pg_toast.pg_toast_2330955080 was the toast part of repack.table_216037680, but pg_toast.pg_toast_216037680 is the toast part of my target table. I don't know how to explain that, but the autovacuum process was started, and here's my main question - why does repack need to acquire an exclusive lock on my target table when executing repack.repack_drop? I saw an issue on GitHub (#55) and a related fix in the code, but in my opinion, if repack executed successfully, it shouldn't have produced this issue, because if the repack_swap executed successfully on the target table, it wouldn't need to be triggered again, and I don't think a deadlock could occur.. So, maybe in the swap function, we need to add a flag to indicate whether the execution was successful. If it was successful, we should not use the lock_exclusive option in the repack_drop stage during the "*"6. Drop." stage execution. So, after my lock timeout of 45 seconds, the repack drop failed.

2025-11-08 13:21:33 UTC [postgres] [26357]: [1] ERROR:  canceling statement due to lock timeout
2025-11-08 13:21:33 UTC [postgres] [26357]: [2] STATEMENT:  LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
2025-11-08 13:21:33 UTC [postgres] [26357]: [3] ERROR:  canceling statement due to lock timeout
2025-11-08 13:21:33 UTC [postgres] [26357]: [4] STATEMENT:  LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
2025-11-08 13:21:33 UTC [postgres] [26357]: [5] ERROR:  canceling statement due to lock timeout
2025-11-08 13:21:33 UTC [postgres] [26357]: [6] STATEMENT:  LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
2025-11-08 13:21:34 UTC [postgres] [26357]: [7] ERROR:  canceling statement due to lock timeout
2025-11-08 13:21:34 UTC [postgres] [26357]: [8] STATEMENT:  LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
2025-11-08 13:21:34 UTC [postgres] [26357]: [9] ERROR:  canceling statement due to lock timeout
2025-11-08 13:21:34 UTC [postgres] [26357]: [10] STATEMENT:  LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
2025-11-08 13:21:35 UTC [postgres] [26357]: [11] ERROR:  canceling statement due to lock timeout
2025-11-08 13:21:35 UTC [postgres] [26357]: [12] STATEMENT:  LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
2025-11-08 13:21:36 UTC [postgres] [26357]: [13] LOG:  process 26357 still waiting for AccessExclusiveLock on relation 1827642466 of database 216037410 after 1000.025 ms
2025-11-08 13:21:36 UTC [postgres] [26357]: [14] DETAIL:  Process holding the lock: 19135. Wait queue: 26357.
2025-11-08 13:21:36 UTC [postgres] [26357]: [15] CONTEXT:  SQL statement "DROP TABLE IF EXISTS repack.table_216037680 CASCADE"
2025-11-08 13:21:36 UTC [postgres] [26357]: [16] STATEMENT:  SELECT repack.repack_drop($1, $2)
2025-11-08 13:22:20 UTC [postgres] [26357]: [17] ERROR:  canceling statement due to lock timeout
2025-11-08 13:22:20 UTC [postgres] [26357]: [18] CONTEXT:  SQL statement "DROP TABLE IF EXISTS repack.table_216037680 CASCADE"
2025-11-08 13:22:20 UTC [postgres] [26357]: [19] STATEMENT:  SELECT repack.repack_drop($1, $2)

and after repack_drop failed that function started again because of whole repack execution failed (repack_cleanup_callback, thats my guess)

DEBUG: Disconnecting worker 0.
DEBUG: Disconnecting worker 1.
DEBUG: Disconnecting worker 2.
DEBUG: Disconnecting worker 3.
DEBUG: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR:  canceling statement due to lock timeout
DETAIL: query was: LOCK TABLE public.my_table IN ACCESS EXCLUSIVE MODE
NOTICE:  trigger "repack_trigger" for relation "public.my_table" does not exist, skipping
ERROR: query failed: ERROR:  canceling statement due to lock timeout
CONTEXT:  SQL statement "DROP TABLE IF EXISTS repack.table_216037680 CASCADE"
DETAIL: query was: SELECT repack.repack_drop($1, $2)

And again my target table was locked due to a trigger that needed to be deleted. However, the swap was completed and the trigger could not be found. This attempt to execute repack_drop also failed. For me this seems a bit strange - the repack_drop failed, and it started again because the previous repack_drop had failed. Perhaps, as I mentioned above, if the repack_swap had been successful, the flag have been set, and my target table would not have been locked for 90 seconds (45 seconds + 45 seconds).
After that, I just recreated the repack extension with the cascade option - this removed both the table in the repack schema and the pk type - without any locks on my target table, as expected.
So, based on my experience, I have a few questions regarding my case:

1. Do you think it would be useful to create a repack.table with autovacuum=off as in repack.log_table? This would prevent the target table from being locked, as in my case, it was locked for 1 second, but it depends on the deadlock_timeout setting (we currently have deadlock_timeout=1s).
2. Perhaps it would be beneficial to add a flag to check whether the repack_swap has completed successfully or not. If the repack_swap completes successfully, the next stage of repack_drop would not need to lock the target table since the repack trigger has been removed by repack_swap. And it should prevent the start of repack_drop again, now in repack_cleanup_callback, if the previous repack_drop failed, because the code almost similar

[za-arthur]

If the repack_swap completes successfully, the next stage of repack_drop would not need to lock the target table since the repack trigger has been removed by repack_swap.

I created a PR to address this case: #473