Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails - Mailing list pgsql-hackers

From Tender Wang
Subject Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Date
Msg-id CAHewXN=sHjKSCzvg2AZu=XjMRxjKKG8Mdw7v434xkNtxc05PSA@mail.gmail.com
Whole thread Raw
In response to Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
List pgsql-hackers


Alvaro Herrera <alvherre@alvh.no-ip.org> 于2024年10月25日周五 16:30写道:
On 2024-Oct-25, Tender Wang wrote:

> Thanks for reporting. I can reproduce this memory invalid access on HEAD.
> After debuging codes, I found the root cause.
>  In DetachPartitionFinalize(), below code:
> att = TupleDescAttr(RelationGetDescr(partRel),
>                                attmap->attnums[conkey[i] - 1] - 1);
>
> We should use confkey[i] -1 not conkey[i] - 1;

Wow, how embarrasing, now that's one _really_ stupid bug and it's
totally my own.  Thanks for the analysis!  I'll get this patched soon.


Hi,

When I debug codes, I find that the way to access AttrMap almost uses "attrmp_ptr->attnums[offset]."
The codes now usually don't check if the offset is out of bounds, which seems unsafe.
Can we wrap an access function? For example:
inline AttrNumber(attrmap_ptr, offset)
{
  Assert(offset >= 0 && offset < attrmap_ptr->maplen);
 return attrmap_ptr->attnums[offset];
}
Or a Macro.

I'm not sure if it's worth doing this.

--
Thanks,
Tender Wang

pgsql-hackers by date:

Previous
From: Nisha Moond
Date:
Subject: Re: Conflict detection for update_deleted in logical replication
Next
From: Alexander Korotkov
Date:
Subject: Re: type cache cleanup improvements