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: <CADzfLwWNv5QDn6qmxCRV-p_ijSTGwNcEZFCOXt09+RmpSG2=+w@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> <8029.1770024929@localhost> <CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg@mail.gmail.com> <27597.1770395398@localhost> <CADzfLwWNv5QDn6qmxCRV-p_ijSTGwNcEZFCOXt09+RmpSG2=+w@mail.gmail.com>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Sat, 07 Feb 2026 15:16:27 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <62226.1770637803.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 09 Feb 2026 12:50:03 +0100
Message-ID: <62227.1770637803@localhost>
Archived-At: <https://www.postgresql.org/message-id/62227.1770637803%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> > Indeed, the server log seems to indicate relationship to
> > VACUUM:
> > 2026-02-01 16:44:58.878 UTC autovacuum worker[22589] LOG:  automatic v=
acuum of table "postgres.pg_catalog.pg_class": index scans: 1
> =

> O, it's a good clue!
> =

> I have added some vacuum calls for pg_class in a stress test - and now i=
t fails much more often (check attachment).
> =

> It is "ERROR:  cache lookup failed for relation" - but I think it may sh=
are the cause with "attempted to overwrite invisible tuple.

I've just reported one issue [1] that causes this, but that does not seem =
to
be related to the "attempted to overwrite invisible tuple" error.

> See:
> https://cirrus-ci.com/build/4852126532239360 - with "Use multiple snapsh=
ots to copy the data."
> https://cirrus-ci.com/build/6429084491710464 - with "Use background work=
er to do logical decoding."
> =

> But I am unable to reproduce the issue with only "Add CONCURRENTLY optio=
n to REPACK command."
> https://cirrus-ci.com/build/6467070524653568

No idea why VACUUM makes the issue happen too often. Maybe it's related to=
 the
PD_ALL_VISIBLE flage, but I've got no detailed explanation. I also don't k=
now
why it does not reproduce w/o the logical decoding worker.

Thanks again for your testing!

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

-- =

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