Re: [HACKERS] [sqlsmith] subplan variable reference / unassigned NestLoopParams

2015-08-10 Thread Tom Lane
Andreas Seltenreich seltenre...@gmx.de writes:
 Tom Lane writes:
 Andreas Seltenreich seltenre...@gmx.de writes:
 Tom Lane writes:
 Well, I certainly think all of these represent bugs:
 3 | ERROR:  plan should not reference subplan's variable
 2 | ERROR:  failed to assign all NestLoopParams to plan nodes

 These appear to be related.  The following query produces the former,
 but if you replace the very last reference of provider with the literal
 'bar', it raises the latter error.

 Fixed that, thanks for the test case!

 I haven't seen the former since your commit, but there recently were
 some instances of the latter.  The attached queries all throw the error
 against master at 8752bbb.

Turns out my patch only addressed some cases of the underlying issue.
I've gone back for a second swipe at it; thanks for the continued testing!

BTW, the commit hashes you've been mentioning don't seem to correspond to
anything in the master PG repo ... are you working with modified sources?

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] [sqlsmith] subplan variable reference / unassigned NestLoopParams

2015-08-08 Thread Andreas Seltenreich
Tom Lane writes:

 Andreas Seltenreich seltenre...@gmx.de writes:
 Tom Lane writes:
 Well, I certainly think all of these represent bugs:
 3 | ERROR:  plan should not reference subplan's variable
 2 | ERROR:  failed to assign all NestLoopParams to plan nodes

 These appear to be related.  The following query produces the former,
 but if you replace the very last reference of provider with the literal
 'bar', it raises the latter error.

 Fixed that, thanks for the test case!

I haven't seen the former since your commit, but there recently were
some instances of the latter.  The attached queries all throw the error
against master at 8752bbb.

regards,
Andreas

-- ERROR:  failed to assign all NestLoopParams to plan nodes
select
  subq_19608926.c0 as c0,
  rel_124211605.objname as c1
from
  (select
   rel_124211602.numeric_precision as c0
 from
   information_schema.sequences as rel_124211602
 where EXISTS (
   select
   rel_124211603.unique_constraint_name as c0
 from
   information_schema.referential_constraints as rel_124211603
 where rel_124211603.unique_constraint_schema is not NULL)) as 
subq_19608926
 left join public.tab1 as rel_124211604
 on (subq_19608926.c0 = rel_124211604.a )
  right join pg_catalog.pg_seclabels as rel_124211605
 right join public.phone as rel_124211606
 on (rel_124211605.objtype = rel_124211606.comment )
  on (rel_124211604.b = rel_124211605.objtype )
inner join public.bt_i4_heap as rel_124211729
  inner join public.bt_i4_heap as rel_124211730
  on (rel_124211729.random = rel_124211730.seqno )
on (subq_19608926.c0 = rel_124211730.seqno )
where rel_124211606.comment = rel_124211604.b;

-- ERROR:  failed to assign all NestLoopParams to plan nodes
select
  subq_53656269.c0 as c0
from
  (select
 rel_339945676.id3c as c0
   from
 public.rule_and_refint_t3 as rel_339945676
   where rel_339945676.data !~~ rel_339945676.data) as subq_53656269
  inner join public.dropcolumn as rel_339945677
  on (subq_53656269.c0 = rel_339945677.b )
inner join public.bt_name_heap as rel_339945678
  left join public.rtest_order2 as rel_339945705
   inner join information_schema.sequences as rel_339945706
   on (rel_339945705.a = rel_339945706.numeric_precision )
 inner join public.num_result as rel_339945707
 on (rel_339945705.b = rel_339945707.id1 )
  on (rel_339945678.random = rel_339945706.numeric_precision )
on (rel_339945677.b = rel_339945706.numeric_precision )
where rel_339945678.seqno ~* rel_339945705.c
fetch first 45 rows only;

-- ERROR:  failed to assign all NestLoopParams to plan nodes
select
  rel_273437910.name as c0,
  rel_273437908.sequence_catalog as c1,
  rel_273437865.b as c2,
  rel_273437910.location as c3,
  rel_273437864.id2c as c4,
  rel_273437908.start_value as c5
from
  public.rule_and_refint_t2 as rel_273437864
  inner join public.ruletest_tbl as rel_273437865
  on (rel_273437864.id2c = rel_273437865.a )
inner join information_schema.sequences as rel_273437908
 inner join public.rules_log as rel_273437909
 on (rel_273437908.numeric_precision_radix = rel_273437909.f1 )
  right join public.emp as rel_273437910
  on (rel_273437909.tag = rel_273437910.name )
on (rel_273437865.a = rel_273437908.numeric_precision )
where rel_273437909.tag !~* rel_273437909.tag
fetch first 110 rows only;

-- ERROR:  failed to assign all NestLoopParams to plan nodes
select
  rel_156464410.minimum_value as c0
from
  public.rule_and_refint_t1 as rel_156464330
  inner join public.rules_src as rel_156464331
  on (rel_156464330.id1b = rel_156464331.f1 )
inner join public.main_table as rel_156464401
  inner join pg_catalog.pg_file_settings as rel_156464402
 left join public.person as rel_156464409
   inner join information_schema.sequences as rel_156464410
   on (rel_156464409.age = rel_156464410.numeric_precision )
 on (rel_156464402.sourceline = rel_156464409.age )
  on (rel_156464401.a = rel_156464402.sourceline )
on (rel_156464331.f1 = rel_156464410.numeric_precision )
where rel_156464402.sourcefile @@ rel_156464409.name
fetch first 155 rows only;

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] [sqlsmith] subplan variable reference / unassigned NestLoopParams (was: [sqlsmith] Failed assertion in joinrels.c)

2015-08-04 Thread Tom Lane
Andreas Seltenreich seltenre...@gmx.de writes:
 Tom Lane writes:
 Well, I certainly think all of these represent bugs:
 3 | ERROR:  plan should not reference subplan's variable
 2 | ERROR:  failed to assign all NestLoopParams to plan nodes

 These appear to be related.  The following query produces the former,
 but if you replace the very last reference of provider with the literal
 'bar', it raises the latter error.

Fixed that, thanks for the test case!

 ,[ FWIW: git bisect run ]
 | first bad commit: [e83bb10d6dcf05a666d4ada00d9788c7974ad378]
 | Adjust definition of cheapest_total_path to work better with LATERAL.
 `

There's still something fishy about your git bisect results; they don't
have much to do with what seems to me to be the triggering condition.
I suspect the problem is that git bisect doesn't allow for the possibility
that the symptom might appear and disappear over time, ie it might have
been visible at some early stage of the LATERAL work but been fixed later,
and then reintroduced by still-later optimization efforts.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] [sqlsmith] subplan variable reference / unassigned NestLoopParams (was: [sqlsmith] Failed assertion in joinrels.c)

2015-08-02 Thread Andreas Seltenreich
Tom Lane writes:

 Well, I certainly think all of these represent bugs:

  3 | ERROR:  plan should not reference subplan's variable
  2 | ERROR:  failed to assign all NestLoopParams to plan nodes

These appear to be related.  The following query produces the former,
but if you replace the very last reference of provider with the literal
'bar', it raises the latter error.

select 1 from
  pg_catalog.pg_shseclabel as rel_09
  inner join public.rtest_view2 as rel_32
  left join pg_catalog.pg_roles as rel_33
  on (rel_32.a = rel_33.rolconnlimit )
  on (rel_09.provider = rel_33.rolpassword )
left join pg_catalog.pg_user as rel_35
on (rel_33.rolconfig = rel_35.useconfig )
where ( ((rel_09.provider ~~ 'foo')
  and (rel_35.usename ~* rel_09.provider)));

,[ FWIW: git bisect run ]
| first bad commit: [e83bb10d6dcf05a666d4ada00d9788c7974ad378]
| Adjust definition of cheapest_total_path to work better with LATERAL.
`

regards,
Andreas


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers