MIME-Version: 1.0
References: <202603162202.l2sibdzviih7@alvherre.pgsql>
 <9548.1773744820@localhost>
 <91049.1773777426@localhost>
In-Reply-To: <91049.1773777426@localhost>
From: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Date: Thu, 19 Mar 2026 00:42:19 +0530
Message-ID: 
 <CAFC+b6qk3-DQTi43QMqvVLP+sudPV4vsLQm5iHfcCeObrNaVyA@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: Antonin Houska <ah@cybertec.at>
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>
Content-Type: multipart/mixed; boundary="000000000000d831d2064d513bc3"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFC%2Bb6qk3-DQTi43QMqvVLP%2BsudPV4vsLQm5iHfcCeObrNaVyA%40mail.gmail.com>
Precedence: bulk

--000000000000d831d2064d513bc3
Content-Type: multipart/alternative; boundary="000000000000d831d0064d513bc1"

--000000000000d831d0064d513bc1
Content-Type: text/plain; charset="UTF-8"

Hello,

While i was doing concurrency test onn V41 patches ,i found this crash
because of the assert failure,

TRAP: failed Assert("RelationGetRelid(relation) == ((RepackDecodingState *)
ctx->output_writer_private)->relid"), File: "pgoutput_repack.c", Line: 97,
PID: 397007
postgres: REPACK decoding worker for relation "stress_victim"
(ExceptionalCondition+0x98)[0xaaaad9361698]
/home/srinath/Desktop/pgbuild/lib/postgresql/pgoutput_repack.so(+0xfe8)[0xffff90e00fe8]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x679e14)[0xaaaad9049e14]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x689cd0)[0xaaaad9059cd0]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x68a65c)[0xaaaad905a65c]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x68b2f0)[0xaaaad905b2f0]
postgres: REPACK decoding worker for relation "stress_victim"
(ReorderBufferCommit+0x74)[0xaaaad905b374]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x671ec4)[0xaaaad9041ec4]
postgres: REPACK decoding worker for relation "stress_victim"
(xact_decode+0x1a0)[0xaaaad9040edc]
postgres: REPACK decoding worker for relation "stress_victim"
(LogicalDecodingProcessRecord+0xd4)[0xaaaad9040a80]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x33f558)[0xaaaad8d0f558]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x341ccc)[0xaaaad8d11ccc]
postgres: REPACK decoding worker for relation "stress_victim"
(RepackWorkerMain+0x1ac)[0xaaaad8d11bd4]
postgres: REPACK decoding worker for relation "stress_victim"
(BackgroundWorkerMain+0x2b0)[0xaaaad900d21c]
postgres: REPACK decoding worker for relation "stress_victim"
(postmaster_child_launch+0x1f0)[0xaaaad9012070]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x64b974)[0xaaaad901b974]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x64bc64)[0xaaaad901bc64]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x64a3e4)[0xaaaad901a3e4]
postgres: REPACK decoding worker for relation "stress_victim"
(+0x647648)[0xaaaad9017648]
postgres: REPACK decoding worker for relation "stress_victim"
(PostmasterMain+0x160c)[0xaaaad9016d98]
postgres: REPACK decoding worker for relation "stress_victim"
(main+0x3dc)[0xaaaad8ea7a38]
/lib/aarch64-linux-gnu/libc.so.6(+0x284c4)[0xffff9c5c84c4]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0xffff9c5c8598]
postgres: REPACK decoding worker for relation "stress_victim"
(_start+0x30)[0xaaaad8abc970]
2026-03-16 19:40:21.622 IST [393820] LOG:  background worker "REPACK
decoding worker" (PID 397007) was terminated by signal 6: Aborted
2026-03-16 19:40:21.622 IST [393820] LOG:  terminating any other active
server processes
2026-03-16 19:40:21.632 IST [397036] FATAL:  the database system is in
recovery mode

This crash happens if we run REPACK (concurrently) on a table while a heavy
pgbench workload is concurrently executing multi-table(setup.sql)
transactions(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 changes
which
slipped under the nose of the change_useless_for_repack filter , which led
some
changes which are not related to the relation which we are currently doing
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
relation during setup_logical_decoding
but this done after DecodingContextFindStartpoint, in
DecodingContextFindStartpoint changes are not
filtered even if its not related to the target relation , because
rm_decode->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 processing
of reorder buffer plugin_change is called
where assert fails, i have attached a diff patch to solve this.

thoughts?

-- 
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

--000000000000d831d0064d513bc1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hello,</div><div><br>While i was doing co=
ncurrency test onn V41 patches ,i found this crash because of the assert fa=
ilure,<br><br>TRAP: failed Assert(&quot;RelationGetRelid(relation) =3D=3D (=
(RepackDecodingState *) ctx-&gt;output_writer_private)-&gt;relid&quot;), Fi=
le: &quot;pgoutput_repack.c&quot;, Line: 97, PID: 397007<br>postgres: REPAC=
K decoding worker for relation &quot;stress_victim&quot; (ExceptionalCondit=
ion+0x98)[0xaaaad9361698]<br>/home/srinath/Desktop/pgbuild/lib/postgresql/p=
goutput_repack.so(+0xfe8)[0xffff90e00fe8]<br>postgres: REPACK decoding work=
er for relation &quot;stress_victim&quot; (+0x679e14)[0xaaaad9049e14]<br>po=
stgres: REPACK decoding worker for relation &quot;stress_victim&quot; (+0x6=
89cd0)[0xaaaad9059cd0]<br>postgres: REPACK decoding worker for relation &qu=
ot;stress_victim&quot; (+0x68a65c)[0xaaaad905a65c]<br>postgres: REPACK deco=
ding worker for relation &quot;stress_victim&quot; (+0x68b2f0)[0xaaaad905b2=
f0]<br>postgres: REPACK decoding worker for relation &quot;stress_victim&qu=
ot; (ReorderBufferCommit+0x74)[0xaaaad905b374]<br>postgres: REPACK decoding=
 worker for relation &quot;stress_victim&quot; (+0x671ec4)[0xaaaad9041ec4]<=
br>postgres: REPACK decoding worker for relation &quot;stress_victim&quot; =
(xact_decode+0x1a0)[0xaaaad9040edc]<br>postgres: REPACK decoding worker for=
 relation &quot;stress_victim&quot; (LogicalDecodingProcessRecord+0xd4)[0xa=
aaad9040a80]<br>postgres: REPACK decoding worker for relation &quot;stress_=
victim&quot; (+0x33f558)[0xaaaad8d0f558]<br>postgres: REPACK decoding worke=
r for relation &quot;stress_victim&quot; (+0x341ccc)[0xaaaad8d11ccc]<br>pos=
tgres: REPACK decoding worker for relation &quot;stress_victim&quot; (Repac=
kWorkerMain+0x1ac)[0xaaaad8d11bd4]<br>postgres: REPACK decoding worker for =
relation &quot;stress_victim&quot; (BackgroundWorkerMain+0x2b0)[0xaaaad900d=
21c]<br>postgres: REPACK decoding worker for relation &quot;stress_victim&q=
uot; (postmaster_child_launch+0x1f0)[0xaaaad9012070]<br>postgres: REPACK de=
coding worker for relation &quot;stress_victim&quot; (+0x64b974)[0xaaaad901=
b974]<br>postgres: REPACK decoding worker for relation &quot;stress_victim&=
quot; (+0x64bc64)[0xaaaad901bc64]<br>postgres: REPACK decoding worker for r=
elation &quot;stress_victim&quot; (+0x64a3e4)[0xaaaad901a3e4]<br>postgres: =
REPACK decoding worker for relation &quot;stress_victim&quot; (+0x647648)[0=
xaaaad9017648]<br>postgres: REPACK decoding worker for relation &quot;stres=
s_victim&quot; (PostmasterMain+0x160c)[0xaaaad9016d98]<br>postgres: REPACK =
decoding worker for relation &quot;stress_victim&quot; (main+0x3dc)[0xaaaad=
8ea7a38]<br>/lib/aarch64-linux-gnu/libc.so.6(+0x284c4)[0xffff9c5c84c4]<br>/=
lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0xffff9c5c8598]<br>=
postgres: REPACK decoding worker for relation &quot;stress_victim&quot; (_s=
tart+0x30)[0xaaaad8abc970]<br>2026-03-16 19:40:21.622 IST [393820] LOG: =C2=
=A0background worker &quot;REPACK decoding worker&quot; (PID 397007) was te=
rminated by signal 6: Aborted<br>2026-03-16 19:40:21.622 IST [393820] LOG: =
=C2=A0terminating any other active server processes<br>2026-03-16 19:40:21.=
632 IST [397036] FATAL: =C2=A0the database system is in recovery mode<br><b=
r>This crash happens if we run REPACK (concurrently) on a table while a hea=
vy<br>pgbench workload is concurrently executing multi-table(setup.sql) tra=
nsactions(dual_chaos.sql).<br>It triggers after a few back to back REPACK (=
concurrently) runs.<br><br>i think i found the cause for this crash , becau=
se there were some changes which<br>slipped under the nose of the=C2=A0chan=
ge_useless_for_repack filter , which led some<br>changes which are not rela=
ted to the relation which we are currently doing REPACK (concurrently)<br>g=
ot decoded and added into the reorderbuffer=C2=A0queue, the reason for this=
 is=C2=A0repacked_rel_locator.relNumber<br>is by default set to=C2=A0Invali=
dOid, this is actually set to the target relation during=C2=A0setup_logical=
_decoding<br>but this done after=C2=A0DecodingContextFindStartpoint, in Dec=
odingContextFindStartpoint changes are not<br>filtered even if its not rela=
ted to the target relation , because rm_decode-&gt;change_useless_for_repac=
k-&gt;am_decoding_for_repack</div><div>where=C2=A0repacked_rel_locator.relN=
umber is still InvalidOid, which makes it skip the filtering even its not t=
he target relation,<br>this makes it to be added to reorder buffer queue, s=
o during the processing of reorder buffer plugin_change is called<br>where =
assert fails, i have attached a diff patch to solve this.<br><br>thoughts?<=
br></div><div><br></div><span class=3D"gmail_signature_prefix">-- </span><b=
r><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><span style=
=3D"color:rgb(34,34,34)">Thanks,</span><br style=3D"color:rgb(34,34,34)"><s=
pan style=3D"color:rgb(34,34,34)">Srinath Reddy Sadipiralla</span><br style=
=3D"color:rgb(34,34,34)"><span style=3D"color:rgb(34,34,34)">EDB:=C2=A0</sp=
an><a href=3D"https://www.enterprisedb.com/" style=3D"color:rgb(17,85,204)"=
 target=3D"_blank">https://www.enterprisedb.com/</a></div></div></div>

--000000000000d831d0064d513bc1--

--000000000000d831d2064d513bc3
Content-Type: application/octet-stream; name="fix_diff.norobots"
Content-Disposition: attachment; filename="fix_diff.norobots"
Content-Transfer-Encoding: base64
Content-ID: <f_mmwey09m0>
X-Attachment-Id: f_mmwey09m0

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2NvbW1hbmRzL2NsdXN0ZXIuYyBiL3NyYy9iYWNrZW5k
L2NvbW1hbmRzL2NsdXN0ZXIuYwppbmRleCA4YjU1NzEzNzRkMC4uNTNiMGZlZjkwNWMgMTAwNjQ0
Ci0tLSBhL3NyYy9iYWNrZW5kL2NvbW1hbmRzL2NsdXN0ZXIuYworKysgYi9zcmMvYmFja2VuZC9j
b21tYW5kcy9jbHVzdGVyLmMKQEAgLTI2NzEsNiArMjY3MSwyMSBAQCBzZXR1cF9sb2dpY2FsX2Rl
Y29kaW5nKE9pZCByZWxpZCkKwqAgwqAgwqAgwqAgwqAqLwrCoCDCoCDCoCDCoCBBc3NlcnQoIWN0
eC0+ZmFzdF9mb3J3YXJkKTsKwqAKKyDCoCDCoCDCoCAvKiBBdm9pZCBsb2dpY2FsIGRlY29kaW5n
IG9mIG90aGVyIHJlbGF0aW9ucy4gKi8KKyDCoCDCoCDCoCByZWwgPSB0YWJsZV9vcGVuKHJlbGlk
LCBBY2Nlc3NTaGFyZUxvY2spOworIMKgIMKgIMKgIHJlcGFja2VkX3JlbF9sb2NhdG9yID0gcmVs
LT5yZF9sb2NhdG9yOworIMKgIMKgIMKgIHRvYXN0cmVsaWQgPSByZWwtPnJkX3JlbC0+cmVsdG9h
c3RyZWxpZDsKKyDCoCDCoCDCoCBpZiAoT2lkSXNWYWxpZCh0b2FzdHJlbGlkKSkKKyDCoCDCoCDC
oCB7CisgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUmVsYXRpb24gwqAgwqAgwqAgwqB0b2FzdHJlbDsK
KworIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC8qIEF2b2lkIGxvZ2ljYWwgZGVjb2Rpbmcgb2Ygb3Ro
ZXIgVE9BU1QgcmVsYXRpb25zLiAqLworIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRvYXN0cmVsID0g
dGFibGVfb3Blbih0b2FzdHJlbGlkLCBBY2Nlc3NTaGFyZUxvY2spOworIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIHJlcGFja2VkX3JlbF90b2FzdF9sb2NhdG9yID0gdG9hc3RyZWwtPnJkX2xvY2F0b3I7
CisgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGFibGVfY2xvc2UodG9hc3RyZWwsIEFjY2Vzc1NoYXJl
TG9jayk7CisgwqAgwqAgwqAgfQorIMKgIMKgIMKgIHRhYmxlX2Nsb3NlKHJlbCwgQWNjZXNzU2hh
cmVMb2NrKTsKKyDCoCDCoCDCoCAKwqAgwqAgwqAgwqAgRGVjb2RpbmdDb250ZXh0RmluZFN0YXJ0
cG9pbnQoY3R4KTsKwqAKwqAgwqAgwqAgwqAgLyoKQEAgLTI3MDcsMjAgKzI3MjIsNyBAQCBzZXR1
cF9sb2dpY2FsX2RlY29kaW5nKE9pZCByZWxpZCkKwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAiUkVQ
QUNLIC0gY2hhbmdlIiwKwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBBTExPQ1NFVF9ERUZBVUxUX1NJ
WkVTKTsKwqAKLSDCoCDCoCDCoCAvKiBBdm9pZCBsb2dpY2FsIGRlY29kaW5nIG9mIG90aGVyIHJl
bGF0aW9ucy4gKi8KLSDCoCDCoCDCoCByZWwgPSB0YWJsZV9vcGVuKHJlbGlkLCBBY2Nlc3NTaGFy
ZUxvY2spOwotIMKgIMKgIMKgIHJlcGFja2VkX3JlbF9sb2NhdG9yID0gcmVsLT5yZF9sb2NhdG9y
Ow==
--000000000000d831d2064d513bc3
Content-Type: application/octet-stream; name="dual_chaos.sql"
Content-Disposition: attachment; filename="dual_chaos.sql"
Content-Transfer-Encoding: base64
Content-ID: <f_mmwf3n9h1>
X-Attachment-Id: f_mmwf3n9h1

XHNldCBpZCByYW5kb21femlwZmlhbigxLCA1MDAwMDAwLCAyLjUpClxzZXQgcmVhZF9pZCByYW5k
b20oMSwgNTAwMDAwMCkKXHNldCB2YWwgcmFuZG9tKDEsIDEwMDApCgpCRUdJTjsKICBVUERBVEUg
c3RyZXNzX3ZpY3RpbSBTRVQgYmFsYW5jZSA9IDp2YWwgV0hFUkUgaWQgPSA6aWQ7CgogIFVQREFU
RSBzdHJlc3Nfc2hhZG93IFNFVCBiYWxhbmNlID0gOnZhbCBXSEVSRSBpZCA9IDppZDsKICAKICBE
RUxFVEUgRlJPTSBzdHJlc3NfdmljdGltIFdIRVJFIGlkID0gOmlkICsgMTsKICBERUxFVEUgRlJP
TSBzdHJlc3Nfc2hhZG93IFdIRVJFIGlkID0gOmlkICsgMTsKICAKICBJTlNFUlQgSU5UTyBzdHJl
c3NfdmljdGltIChpZCwgYmFsYW5jZSwgcGF5bG9hZCkgCiAgVkFMVUVTICg6aWQgKyAxLCA6dmFs
LCAnbmV3JykKICBPTiBDT05GTElDVCAoaWQpIERPIFVQREFURSBTRVQgYmFsYW5jZSA9IEVYQ0xV
REVELmJhbGFuY2UsIHBheWxvYWQgPSBFWENMVURFRC5wYXlsb2FkOwogIAogIElOU0VSVCBJTlRP
IHN0cmVzc19zaGFkb3cgKGlkLCBiYWxhbmNlLCBwYXlsb2FkKSAKICBWQUxVRVMgKDppZCArIDEs
IDp2YWwsICduZXcnKQogIE9OIENPTkZMSUNUIChpZCkgRE8gVVBEQVRFIFNFVCBiYWxhbmNlID0g
RVhDTFVERUQuYmFsYW5jZSwgcGF5bG9hZCA9IEVYQ0xVREVELnBheWxvYWQ7CkNPTU1JVDs=
--000000000000d831d2064d513bc3
Content-Type: application/octet-stream; name="setup.sql"
Content-Disposition: attachment; filename="setup.sql"
Content-Transfer-Encoding: base64
Content-ID: <f_mmwf3n9l2>
X-Attachment-Id: f_mmwf3n9l2

RFJPUCBUQUJMRSBJRiBFWElTVFMgc3RyZXNzX3ZpY3RpbTsKRFJPUCBUQUJMRSBJRiBFWElTVFMg
c3RyZXNzX3NoYWRvdzsKCkNSRUFURSBUQUJMRSBzdHJlc3NfdmljdGltICgKICAgIGlkIFNFUklB
TCBQUklNQVJZIEtFWSwKICAgIGJhbGFuY2UgSU5ULAogICAgcGF5bG9hZCBURVhUCik7CgpDUkVB
VEUgVEFCTEUgc3RyZXNzX3NoYWRvdyAoCiAgICBpZCBTRVJJQUwgUFJJTUFSWSBLRVksCiAgICBi
YWxhbmNlIElOVCwKICAgIHBheWxvYWQgVEVYVAopOwoKSU5TRVJUIElOVE8gc3RyZXNzX3ZpY3Rp
bSAoYmFsYW5jZSwgcGF5bG9hZCkKU0VMRUNUIAogICAgKHJhbmRvbSgpKjEwMDApOjppbnQsIAog
ICAgcmVwZWF0KG1kNShyYW5kb20oKTo6dGV4dCksIDYpCkZST00gZ2VuZXJhdGVfc2VyaWVzKDEs
IDUwMDAwMDApOwoKSU5TRVJUIElOVE8gc3RyZXNzX3NoYWRvdyBTRUxFQ1QgKiBGUk9NIHN0cmVz
c192aWN0aW07Cg==
--000000000000d831d2064d513bc3--