Re: [sqlsmith] Planner crash on foreign table join

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Andreas Seltenreich <seltenreich(at)gmx(dot)de>, pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: [sqlsmith] Planner crash on foreign table join
Date: 2017-04-08 16:27:43
Message-ID: 11491.1491668863@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Andreas" == Andreas Seltenreich <seltenreich(at)gmx(dot)de> writes:
> Andreas> testing master at f0e44021df with a loopback postgres_fdw
> Andreas> installed, I see lots of crashes on queries joining foreign
> Andreas> tables with various expressions. Below is a reduced recipe
> Andreas> for the regression database and a backtrace.

> Commit ac2b095088 assumes that clauselist_selectivity is being passed a
> list of RelOptInfo, but postgres_fdw is passing it a list of bare
> clauses. One of them is wrong :-)

It's a bit scary that apparently none of the committed regression tests
caught that.

More generally, I think the convention up to now has been that
clauselist_selectivity would work on either RestrictInfos or bare boolean
clauses, caching its results in the former case but succeeding anyway.
If we're to standardize on only one of those behaviors it should certainly
be the former, but I think postgres_fdw is probably not the only code that
will be broken if we remove the option for the latter.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-04-08 16:50:19 Re: [HACKERS] Small issue in online devel documentation build
Previous Message Heikki Linnakangas 2017-04-08 16:12:44 Re: Fwd: Re: Running make check-world in buildfarm (was Re: [COMMITTERS] pgsql: Use SASLprep to normalize passwords for SCRAM authentication.)