On Sat, Aug 30, 2025 at 10:29 PM Alexander Korotkov <[email protected]> wrote: > On Sat, Aug 30, 2025 at 9:54 PM Alexander Korotkov <[email protected]> > wrote: > > On Sat, Aug 30, 2025 at 4:00 PM Alexander Lakhin <[email protected]> > > 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.
The same patch with a bit revised comment and commit message. ------ Regards, Alexander Korotkov Supabase
v2-0001-Fix-the-operation-order-in-get_relation_constrain.patch
Description: Binary data
