Andreas Seltenreich <seltenre...@gmx.de> writes:
> I let sqlsmith run during the night, and it did no longer trigger the
> first two. During roughly a million random queries it triggered the
> already mentioned brin one 10 times, but there was also one instance of
> this new one in the log:
> TRAP: FailedAssertion("!(join_clause_is_movable_into(rinfo, joinrel->relids,
> join_and_req))", File: "relnode.c", Line: 987)
> LOG: server process (PID 12851) was terminated by signal 6: Aborted
> DETAIL: Failed process was running: select
> rel65543066.tmplname as c0,
> rel65543064.umuser as c1
> from
> public.dept as rel65543059
> inner join pg_catalog.pg_user_mappings as rel65543064
> left join pg_catalog.pg_enum as rel65543065
> on (rel65543064.srvname = rel65543065.enumlabel )
> inner join pg_catalog.pg_ts_template as rel65543066
> on (rel65543065.enumtypid = rel65543066.tmplnamespace )
> on (rel65543059.dname = rel65543064.srvname )
> where ((rel65543059.mgrname = rel65543059.mgrname)
> and (rel65543064.usename = rel65543066.tmplname))
> and (rel65543059.mgrname ~~ rel65543059.mgrname)
> fetch first 128 rows only;
I looked into this one. What seems to be the story is that
join_clause_is_movable_into() is approximate in the conservative
direction, that is it sometimes can return "false" when a strict analysis
would conclude "true" (a fact that is undocumented in its comments;
I shall fix that). This is acceptable, as long as the answers are
consistent across different jointree levels, since the worst consequence
is that we might fail to push a join clause as far down the jointree as it
could be pushed. However, the Assert that's failing here supposes that
the answer is exact. I think a sufficient fix in the near term is to
disable that Assert and add suitable commentary. In the long run it might
be nice if the answers were exact, but that would require more information
than is currently passed to join_clause_is_movable_into(), which would
imply non-back-patchable API changes.
> ,----[ git bisect ]
> | first bad commit: [3f8c23c4d31d4a0e801041733deb2c7cfa577b32] Improve
> | predtest.c's ability to reason about operator expressions.
> `----
There seems to be something odd going on with your bisection tests,
because once again the query fails clear back to 9.2 for me, which is what
I'd expect based on the above analysis --- the movable-join-clause logic
all came in with parameterized paths in 9.2.
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
