From: Antonin Houska <ah@cybertec.at>
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Matthias van de Meent <boekewurm+postgres@gmail.com>,
    Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: 
 <CAFC+b6qk3-DQTi43QMqvVLP+sudPV4vsLQm5iHfcCeObrNaVyA@mail.gmail.com>
References: <202603162202.l2sibdzviih7@alvherre.pgsql>
 <9548.1773744820@localhost> <91049.1773777426@localhost>
 <CAFC+b6qk3-DQTi43QMqvVLP+sudPV4vsLQm5iHfcCeObrNaVyA@mail.gmail.com>
Comments: In-reply-to Srinath Reddy Sadipiralla <srinath2133@gmail.com>
   message dated "Thu, 19 Mar 2026 00:42:19 +0530."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <98416.1773864429.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Mar 2026 21:07:09 +0100
Message-ID: <98417.1773864429@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/98417.1773864429%40localhost>
Precedence: bulk

Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote:

> TRAP: failed Assert("RelationGetRelid(relation) =3D=3D ((RepackDecodingS=
tate *) ctx->output_writer_private)->relid"), File: "pgoutput_repack.c",
> Line: 97, PID: 397007

> This crash happens if we run REPACK (concurrently) on a table while a he=
avy
> pgbench workload is concurrently executing multi-table(setup.sql) transa=
ctions(dual_chaos.sql).
> It triggers after a few back to back REPACK (concurrently) runs.
> =

> i think i found the cause for this crash , because there were some chang=
es which
> slipped under the nose of the change_useless_for_repack filter , which l=
ed some
> changes which are not related to the relation which we are currently doi=
ng REPACK (concurrently)
> got decoded and added into the reorderbuffer queue, the reason for this =
is repacked_rel_locator.relNumber
> is by default set to InvalidOid, this is actually set to the target rela=
tion during setup_logical_decoding
> but this done after DecodingContextFindStartpoint, in DecodingContextFin=
dStartpoint changes are not
> filtered even if its not related to the target relation , because rm_dec=
ode->change_useless_for_repack->am_decoding_for_repack
> where repacked_rel_locator.relNumber is still InvalidOid, which makes it=
 skip the filtering even its not the target relation,
> this makes it to be added to reorder buffer queue, so during the process=
ing of reorder buffer plugin_change is called
> where assert fails, i have attached a diff patch to solve this.

Thanks a lot! Yes, your explanation makes sense. I'll include the fix in t=
he
next version. I think it might also explain the other crash [1] you report=
ed
earlier. I'll try to reproduce that.

[1] https://www.postgresql.org/message-id/CAFC%2Bb6o2yzA80YmfEhmMO9puN8qvG=
Rvr-15BBLn3UmJxPfpr2w%40mail.gmail.com

-- =

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