Hi Srinath,
On 2026-Mar-19, Srinath Reddy Sadipiralla wrote:
> 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.
Ah, thanks for tracking this down -- I've been seeing this crash also.
So here's v43. Here, I've changed the CONCURRENTLY implementation to go
through table AM. This necessitated changing it to use tuples in slots
instead of HeapTuple. This is good because we can avoid repeated tuple
form/deform, which could get pretty expensive. Antonin's 0004 patch
here looks suspicious here though, because it deforms the tuple and
forms it again, which sounds unnecessary now.
Not yet committable; the change to use slots and table AM is a rather
significant modification to what was before. Barring cosmetics and code
reorganization, it should be close enough.
I included your (Srinath's) patch as 0005. The file you sent is corrupt
though, so I applied the visible part of change manually, in addition to
removing the rest of the block that the patch somehow doesn't remove.
This also includes as part of 0003 the change to table AM options I sent in
[1]. I will probably commit that change in the way that the other thread
decides, and then rebase this on top of that.
[1] https://postgr.es/m/202603171606.kf6pmhscqbqz@alvherre.pgsql
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
