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: <CADzfLwUukiGOPoUkDgf6oEB-Y0TnNy6UFUN4obnU-AN5W1N=sw@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> <57210.1769801636@localhost> <CADzfLwUukiGOPoUkDgf6oEB-Y0TnNy6UFUN4obnU-AN5W1N=sw@mail.gmail.com>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Sun, 01 Feb 2026 20:46:31 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8028.1770024929.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 02 Feb 2026 10:35:29 +0100
Message-ID: <8029.1770024929@localhost>
Archived-At: <https://www.postgresql.org/message-id/8029.1770024929%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> PART 1:
> =

> --------------
> =

> Something still wrong with 0006, check:
> =

> 'pgbench: error: client 12 script 0 aborted in command 2 query 0: ERROR:=
  attempted to overwrite invisible tuple
> https://cirrus-ci.com/task/6385612527239168?logs=3Dtest_world#L300
> =

> But it is hard to reproduce - happened once.
> =

> --------------
> =

> Also, once I got
> [16:25:18.641] #   at /tmp/cirrus-ci-build/contrib/amcheck/t/007_repack_=
concurrently.pl line 57.
> [16:25:18.641] #                   'pgbench: error: client 6 script 0 ab=
orted in command 2 query 0: ERROR:  relation 21856 deleted while still in =
use
> https://cirrus-ci.com/task/4686014242881536?logs=3Dtest_world#L384
> =

> It was the PROC_IN_REPACK version (see below), but I think it is not rel=
ated to it. But I'm not 100% sure.

I think it *is* related. My earlier patch version, which used the
PROC_IN_VACUUM flag improperly [1] was also causing visibility issues.  Pl=
ease
let me know if you manage to reproduce the issue with v32.

> PART 2:
> =

> > I'm considering a special kind of relation whose catalog entries remai=
n in the
> >  catalog cache and are never written to the catalog tables. (Unlike te=
mporary
> >  relation, it'd be WAL logged so that REPACK can be replayed on standb=
y.)
> =

> I think it is too complicated, especially including replication logic.

I'm confused by hearing a complaint about complexity of code that I haven'=
t
posted yet. And I don't understand the relationship to "replication logic"=
:
REPACK (CONCURRENTLY) tries to avoid decoding of data changes in the *new*
(transient) relation anyway.

> Essentially we have two issues:
> 1) make sure catalog entities are not dropped because the vacuum
> 2) make sure data in new table is not vacuumed also

3) XID assigned early due to creation of catalog entries for the new table=
 -
that XID prevents the VACUUM xmin horizon from advancing till the end of t=
he
transaction, i.e. till the end of REPACK execution.

> Also, I am still not sure if MVCC-safe implementation is worth its compl=
exity compared with "relcheckxmin"approach [0].

IMO it's better for users to see the correct data than ERROR. But it still
needs work.

[1] https://www.postgresql.org/message-id/88003.1769511456%40localhost

-- =

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