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: <57209.1769801636.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 30 Jan 2026 20:33:56 +0100
Message-ID: <57210.1769801636@localhost>
Archived-At: <https://www.postgresql.org/message-id/57210.1769801636%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> > PROC_IN_VACUUM shouldn't be used for the same reason StartupDecodingCo=
ntext()
> >  avoids setting PROC_IN_LOGICAL_DECODING in transaction. I've removed =
that and
> >  the tests work for me. Especially the "cache lookup failed" error is =
almost
> >  certainly related. Please let me know if you still get the other erro=
rs
> =

> Yes, now it is passing.
> =

> >  (Except for 2, which is probably due to the MVCC-unsafe behavior, as =
discussed
> >  earlier.)
> =

> Not happening too. BTW, it was non MVCC-related, because in that case re=
lcheckxmin would catch it.
> =

> What if:
> =

> 1) add new PROC_IN_REPACK flag
> 2) use it in catalog horizon, but not in data (like was done in [0] for =
PROC_IN_SAFE_IC)
> =

> And after we have options:
>     3) do not "table_close(NewHeap, NoLock);" - keep ShareUpdateExclusiv=
eLock all the time to prevent VACUUM enter
>     4) do not heap_page_prune_opt in repack transaction (just using simp=
le flag)
> Or
>     3) preserve xmin/xmax of original transaction in repacked data
>     4) but better to keep ShareUpdateExclusiveLock anyway

I've been thinking of another approach. Note that REPACK creates a new tab=
le
only to eventually swap the relation files and drop it. Thus the transacti=
ons
needs to get XID assigned very soon.

I'm considering a special kind of relation whose catalog entries remain in=
 the
catalog cache and are never written to the catalog tables. (Unlike tempora=
ry
relation, it'd be WAL logged so that REPACK can be replayed on standby.)

If we eventually implement the MVCC safety, XID will neither be needed dur=
ing
data copying. And it shouldn't even be needed to build indexes, as long as
their catalog entries are also "cache only". Thus the transaction REPACK i=
s
running in would not need XID until the data has been copied, indexes buil=
t
and even (most of) the concurrent data changes replayed. Only the final
catalog changes would require XID, but those should take very short time.

Without XID and with the snapshot resetting, REPACK should not really bloc=
k
the progress of the VACUUM xmin horizon.

-- =

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