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: <CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg@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>
Comments: In-reply-to Mihail Nikalayeu <mihailnikalayeu@gmail.com>
   message dated "Mon, 02 Feb 2026 11:04:45 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27596.1770395398.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 06 Feb 2026 17:29:58 +0100
Message-ID: <27597.1770395398@localhost>
Archived-At: <https://www.postgresql.org/message-id/27597.1770395398%40localhost>
Precedence: bulk

Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

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

> Will try. Just to highlight - first error happened on v31 *without* PROC=
_IN_REPACK.

I spent some time running the test with your branch (based on v32 as you t=
old
me off-list), but couldn't reproduce the problem.

The related code is in heap_inplace_lock():

    /* no known way this can happen */
    ereport(ERROR,
		    (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
		     errmsg_internal("attempted to overwrite invisible tuple")));


The only path REPACK (CONCURRENTLY) uses in-place update seems to be:

cluster.c:build_new_indexes() -> index_create_copy() -> index_create() ->
index_build() -> index_update_stats() -> systable_inplace_update_begin()


However I've got no idea how this can be related to REPACK. Since the new
index is not visible to other transactions until REPACK is done, VACUUM sh=
ould
be the only process able to change the tuple before
heap_inplace_lock(). Indeed, the server log seems to indicate relationship=
 to
VACUUM:

2026-02-01 16:44:58.878 UTC autovacuum worker[22589] LOG:  automatic vacuu=
m of table "postgres.pg_catalog.pg_class": index scans: 1
...
2026-02-01 16:44:58.884 UTC client backend[12737] 008_repack_concurrently.=
pl LOG:  statement: COMMIT;
2026-02-01 16:44:58.884 UTC client backend[12737] 008_repack_concurrently.=
pl LOG:  statement: SELECT pg_try_advisory_lock(42)::integer AS gotlock =

2026-02-01 16:44:58.884 UTC client backend[12737] 008_repack_concurrently.=
pl LOG:  statement: SELECT pg_advisory_lock(43);
2026-02-01 16:44:58.884 UTC client backend[12737] 008_repack_concurrently.=
pl LOG:  statement: BEGIN;
2026-02-01 16:44:58.884 UTC client backend[12737] 008_repack_concurrently.=
pl LOG:  statement: INSERT INTO tbl(j) VALUES (nextval('last_j')) RETURNIN=
G j =

2026-02-01 16:44:58.885 UTC client backend[12727] 008_repack_concurrently.=
pl LOG:  statement: SELECT COUNT(*) AS count FROM tbl WHERE j <=3D 14148 =

2026-02-01 16:44:58.885 UTC client backend[12734] 008_repack_concurrently.=
pl LOG:  statement: SELECT COUNT(*) AS count FROM tbl WHERE j <=3D 14145 =

2026-02-01 16:44:58.885 UTC client backend[12737] 008_repack_concurrently.=
pl LOG:  statement: COMMIT;
2026-02-01 16:44:58.885 UTC client backend[12737] 008_repack_concurrently.=
pl LOG:  statement: SELECT pg_advisory_unlock(43);
2026-02-01 16:44:58.887 UTC client backend[12737] 008_repack_concurrently.=
pl LOG:  statement: BEGIN
				--TRANSACTION ISOLATION LEVEL REPEATABLE READ
				;
2026-02-01 16:44:58.887 UTC client backend[12737] 008_repack_concurrently.=
pl LOG:  statement: SELECT 1;
2026-02-01 16:44:58.891 UTC REPACK decoding worker[22621] FATAL:  terminat=
ing background worker "REPACK decoding worker" due to administrator comman=
d
2026-02-01 16:44:58.896 UTC client backend[12740] 008_repack_concurrently.=
pl LOG:  statement: SELECT COUNT(*) AS count FROM tbl WHERE j <=3D 14146 =

2026-02-01 16:44:58.896 UTC client backend[12722] 008_repack_concurrently.=
pl ERROR:  attempted to overwrite invisible tuple
2026-02-01 16:44:58.896 UTC client backend[12722] 008_repack_concurrently.=
pl STATEMENT:  REPACK (CONCURRENTLY) tbl USING INDEX tbl_pkey;


However, VACUUM should not touch the tuple because the scan in
systable_inplace_update_begin() should leave the containing buffer pinned.=
 I
wonder if you managed to hit another existing bug.

-- =

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