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

From: Alvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: shihao zhong <zhong950419(at)gmail(dot)com>, 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-10-06 20:05:42
Message-ID: asVTolvgFFWEkADn@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-Oct-06, Antonin Houska wrote:

> I suspect there's a thinko in the "Notes on Resources" section. Shouldn't the
> first paragraph start like this?
>
> "When the USING INDEX clause is given and an index scan is chosen, ..."

Hmm, no -- this paragraph tries to explain what happens when we use the
unsorted option, _or_ we use the sorted option but we use a indexscan to
implement it. So either the VACUUM FULL, or the indexscan based
CLUSTER. In this case we only have one extra copy of the table.

The second paragraph tries to describe what happens when we use a
seqscan and sort -- that is, we have USING INDEX, but we don't scan
using that index (that is, CLUSTER that uses a sort). That requires
additional storage (the tuplestore that is sorted).

Maybe we need to reword both so that this is more obvious?

> No objections regarding the "Notes on Concurrent Operation" section.

Thanks for reading!

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2026-10-06 20:08:28 Re: REPACK (CONCURRENTLY): do not block the table while waiting for the final lock
Previous Message Sami Imseih 2026-10-06 19:40:30 Re: Show effective xmin in pg_replication_slots when xmin is not set