From: Antonin Houska <ah@cybertec.at>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <CADzfLwXdaJh4awQstc2PpBz=EBBc6tMA50wYLqMoEtY5B+WUnA@mail.gmail.com>
References: <202512151349.vlq3mpfniyk3@alvherre.pgsql> <11247.1767609087@localhost> <11558.1767609632@localhost> <141054.1767891540@localhost> <CADzfLwU-OmxW3t3AoQo9=K7uq4G1yZ-txcetzW3jbcVxV_pJew@mail.gmail.com> <137668.1768235610@localhost> <CADzfLwUJSHKGxYw+vMUZ_Hr2YeuxO2Q5w13HKgUUN1725tjY5Q@mail.gmail.com> <CADzfLwXJ+4s1tJuG9injcxAUP3urj9D6dUAPOCaX33UeiUxrRQ@mail.gmail.com> <74802.1769071060@localhost> <CADzfLwVZ_DeU_3avD=G4ZHFJJgZ0EOFzxnmWxwyB23zsS-uxjA@mail.gmail.com> <CADzfLwUEH5+LjCN+6kRfSsXwuou8rKXyVV42Wi-O_TG0360Kug@mail.gmail.com> <3901.1769412880@localhost> <88003.1769511456@localhost> <CADzfLwXdaJh4awQstc2PpBz=EBBc6tMA50wYLqMoEtY5B+WUnA@mail.gmail.com>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Wed, 28 Jan 2026 03:06:00 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5366.1770017148.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 02 Feb 2026 08:25:48 +0100
Message-ID: <5367.1770017148@localhost>
Archived-At: <https://www.postgresql.org/message-id/5367.1770017148%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> > The 0006 part needs more work (definitely beyond PG 19).
> =

> This is sad, because if you are in a situation then you need REPACK - pi=
nning the horizon for too long may just finish your DB....
> And also, even with 0006 we still need to build indexes, which might pin=
 it for long (even duration caused by a single index).

I suppose "to finish database" refers to XID wraparound - a problem that y=
ou
keep mentioning again and again. (Yes, the wraparound is a problem, but no=
t
exactly a "final" state of the database.)

As far as I know, it's not uncommon for DBAs to use the pg_repack extensio=
n,
and this extension also restricts the progress of the VACUUM xmin horizon.=
 Are
you sure that users do complain about having ended up in the XID wraparoun=
d
situation?

I don't really pay attention to pg_repack, but I do pay quite some attenti=
on
to the pg_squeeze extension (which I wrote and maintain). I recall that so=
me
users were surprised by the amount of disk space consumed (as the earlier
versions of pg_squeeze were "too lazy" about WAL decoding), but I do not
recall a single complaint about pg_squeeze causing the XID wraparound
situation.

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com