Horton

Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails

Tender Wang <tndrwang@gmail.com>

View thread View on postgr.es
From: Tender Wang <tndrwang@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Alexander Lakhin <exclusion@gmail.com>, Jehan-Guillaume de Rorthais <jgdr@dalibo.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Guillaume Lelarge <guillaume@lelarge.info>
Date: 2024-10-25T09:06:38Z
Lists: 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

Commits

  1. Fix some more bugs in foreign keys connecting partitioned tables

  2. Restructure foreign key handling code for ATTACH/DETACH

  3. Create foreign key triggers in partitioned tables too