Hi, On Sat, Sep 26, 2026 at 11:15 AM Amit Langote <[email protected]> wrote: > On Fri, Sep 25, 2026 at 8:45 PM Matheus Alcantara > <[email protected]> wrote: > > On 25/09/26 05:16, Amit Langote wrote: > > >> ri_CheckFunctionPermissions(riinfo, fpmeta) passes both when fpmeta > > >> == riinfo->fpmeta. I'm wondering if we could just pass riinfo? > > > > > > That's just for consistency with build_index_scankeys(); it isn't > > > needed, so I don't feel strongly either way. > > > > > > > Ok, make sense. > > > > >> IIUC this patch only fix the case for FastPath without batching right? > > >> Since batching is still on master, I'm wondering if we could also fix > > >> it. See attached patch (v2-0001 is your v1-0001). > > > > > > I've left the batch code alone because I intend to revert it from > > > master too sometime next week. Thanks for the patch, though. > > > > > > > Ok, thanks for letting me know. > > > > > I have attached a new version where I polished > > > ri_CheckFunctionPermissions()'s comment and the commit message. I > > > would like to commit it tomorrow if there are no more comments. > > > > > > > Looks good to me. > > Thanks, pushed.
A review of the fast-path code using Opus 5.5 found a potential NULL de-reference after this commit. ri_FastPathCheck() reads riinfo->fpmeta again after ri_CheckFunctionPermissions(), whose catalog lookups can process an invalidation that detaches the metadata and sets riinfo->fpmeta to NULL. The attached patch keeps a local pointer, as InvalidateConstraintCacheCallBack() already assumes callers do. It applies to both master and REL_19_STABLE. Also, there's no batching code anymore to keep in sync as of last Saturday [1]. -- Thanks, Amit Langote [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=425daf545d9146e008220ae0b21415982220cd3f
v1-0001-Fix-possible-crash-when-RI-fast-path-metadata-is-.patch
Description: Binary data
