| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'Alvaro Herrera' <alvherre(at)alvh(dot)no-ip(dot)org>, Antonin Houska <ah(at)cybertec(dot)at> |
| Cc: | Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | RE: Adding REPACK [concurrently] |
| Date: | 2026-04-04 06:20:35 |
| Message-ID: | OS9PR01MB121494749F57A32A17D73F4B1F55FA@OS9PR01MB12149.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dear Álvaro,
While testing REPACK CONCURRENTLY command with xid_wraparound module, noticed that
wraparound-autovac worker was terminated with an error like below.
``
ERROR: could not wait for concurrent REPACK
DETAIL: Process 41512 waits for REPACK running on process 41027
CONTEXT: waiting for ShareUpdateExclusiveLock on relation 16384 of database 5
automatic vacuum of table "postgres.public.test"
```
The behavior is different from other commands, like LOCK and maybe normal REPACK.
In these cases the autovac worker would wait till the command fails.
Is it an intentional behavior? If so, what is the advantage that we terminate the
failsafe vacuum?
Best regards,
Hayato Kuroda
FUJITSU LIMITED
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-04-04 07:31:13 | Re: Row pattern recognition |
| Previous Message | Andres Freund | 2026-04-04 05:33:32 | Re: index prefetching |