Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: Radim Marek <radim(at)boringsql(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes
Date: 2026-09-27 15:53:36
Message-ID: CAGRkXqTg-wioCAEWchmieGR3xw5=X4-EgKoDYfT-Cv54dzye1g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Antonin,

> I think that the most important thing for the user to know is that the
purpose
> of REPACK is to improve performance (via bloat removal and/or clustering),
> whereas "failsafe VACUUM" (i.e. VACUUM with INDEX_CLEANUP set to off)
should
> be used to avoid the risk of XID wraparound.
>
> I don't have a good idea about the wording right now.

Here is a try with Fable, as v2 of Radim's patch.

It adds a paragraph to Notes. REPACK is for bloat and clustering. For
wraparound uses VACUUM, because REPACK takes much longer and can fail
late.

Thanks,
Shihao

Attachment Content-Type Size
v2-0001-doc-Document-REPACK-limits-and-point-to-VACUUM-fo.patch application/octet-stream 2.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-09-27 15:54:48 Re: [PATCH] Planner support function for generate_subscripts()
Previous Message shihao zhong 2026-09-27 15:51:16 Re: Reset waitStart when a lock wait fails