| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout |
| Date: | 2026-09-24 02:52:22 |
| Message-ID: | CAGRkXqTsaz9TaioKV0ghofSkAA_sEzKTnxtufRNkuTWbKSCAug@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manu | 2026-09-24 03:08:04 | Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten |
| Previous Message | Manu | 2026-09-24 02:50:43 | Re: index prefetching |