On Sat, Aug 30, 2025 at 9:54 PM Alexander Korotkov <aekorot...@gmail.com> wrote:
> On Sat, Aug 30, 2025 at 4:00 PM Alexander Lakhin <exclus...@gmail.com> wrote:
> >
> > Hello Alexander,
> >
> > 24.08.2025 03:44, Alexander Korotkov wrote:
> >
> > Thank you for catching this.  And thank you for the fix.  I think it
> > worth separating fix and refactoring.  This helps to understand what
> > exactly the fix is by looking at the patch.  I also edited commit
> > message.  I'm going to push this if no objections.
> >
> >
> > Please try the following script:
> > create table t1(i1 int primary key);
> > create table t2 (i2 int, check (i2 is not null));
> >
> > set constraint_exclusion = 'on';
> >
> > select 1 from t1 right join t2 on i1 = i2 where (select true);
> >
> > which triggers (starting from 5f6f951f8):
> > Core was generated by `postgres: law regression [local] SELECT              
> >                          '.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0  0x000058dd6a7b6014 in var_is_nonnullable (root=0x58dd78d505f8, 
> > var=0x58dd78d75610, use_rel_info=false) at clauses.c:4242
> > 4242                    if (rte->inh && rte->relkind != 
> > RELKIND_PARTITIONED_TABLE)
> > (gdb) bt
> > #0  0x000058dd6a7b6014 in var_is_nonnullable (root=0x58dd78d505f8, 
> > var=0x58dd78d75610, use_rel_info=false) at clauses.c:4242
> > #1  0x000058dd6a7b4f74 in eval_const_expressions_mutator 
> > (node=0x58dd78d75590, context=0x7fff875a9f00) at clauses.c:3556
> > #2  0x000058dd6a7b2935 in eval_const_expressions (root=0x58dd78d505f8, 
> > node=0x58dd78d75590) at clauses.c:2272
> > #3  0x000058dd6a7c857d in get_relation_constraints (root=0x58dd78d505f8, 
> > relationObjectId=16385, rel=0x58dd78d738e0, include_noinherit=true, 
> > include_notnull=true, include_partition=true) at plancat.c:1419
> > #4  0x000058dd6a7c8fdb in relation_excluded_by_constraints 
> > (root=0x58dd78d505f8, rel=0x58dd78d738e0, rte=0x58dd78c6b968) at 
> > plancat.c:1808
> > #5  0x000058dd6a73675e in set_rel_size (root=0x58dd78d505f8, 
> > rel=0x58dd78d738e0, rti=2, rte=0x58dd78c6b968) at allpaths.c:364
> > #6  0x000058dd6a73664c in set_base_rel_sizes (root=0x58dd78d505f8) at 
> > allpaths.c:322
> > #7  0x000058dd6a73631e in make_one_rel (root=0x58dd78d505f8, 
> > joinlist=0x58dd78d74a90) at allpaths.c:183
>
> Thank you for pointing.  I'm investigating this now.

Hmm... It seems that commit 5f6f951f88 spotted some existing bug.
get_relation_constraints() deserializes the constraint node, but it
initially refers varno == 1.  get_relation_constraints() calls
ChangeVarNodes() to change varno from 1 to 2, but only after calling
eval_const_expressions() which access root->simple_rte_array[] with
wrong varno...

The draft patch fixing this is attached.  I will continue the investigation.

------
Regards,
Alexander Korotkov
Supabase

Attachment: fix_get_relation_constraints.patch
Description: Binary data

Reply via email to