On Fri, Jan 19, 2018 at 10:40 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jan 19, 2018 at 1:53 AM, Etsuro Fujita >> <fujita.ets...@lab.ntt.co.jp> wrote: >>> I noticed that this test case added by the patch is not appropriate: >>> because it doesn't inject extra Sort nodes into EPQ recheck plans, so it >>> works well without the fix. I modified this to inject a Sort into the >>> recheck plan of the very first foreign join. Attached is a patch for that. > >> Mumble. Tom provided me with that example and said it failed without >> the patch. I didn't check, I just believed him. But I'm surprised if >> he was wrong; Tom usually tries to avoid being wrong... > > Hm. It did fail as advertised when I connected to the contrib_regression > database (after installcheck) and entered the query by hand; I > copied-and-pasted the result of that to show you. It's possible that it > would not have failed in the particular spot where you chose to insert it > in the regression script, if for example there were nondefault planner GUC > settings active at that spot. Did you check that the script produced the > expected failure against unpatched code?
No. I guess I'll have to go debug this. Argh. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
