Re: regressplans failures

Peter Eisentraut <peter_e@gmx.net> writes:
> #3  0x8149b98 in ExceptionalCondition (
>     conditionName=0x81988a0 "!(((file) > 0 && (file) < (int) SizeVfdCache
> && VfdCache[file].fileName != ((void *)0)))", exceptionP=0x81b93c8,
> detail=0x0,
>     fileName=0x8198787 "fd.c", lineNumber=851) at assert.c:70
> #4  0x8105e6e in FileSeek (file=33, offset=0, whence=2) at fd.c:851

I'm guessing this is a variant of the problem Philip Warner reported
yesterday.  Probably WAL-related.  Vadim?

> The only other two failures are the join test when both merge and hash
> joins are disabled and alter_table without index scans.  Both seem
> harmless; see attached diffs.
> The former is related to outer joins apparently not working with nest
> loops.  The latter is a missing ORDER BY, which I'm inclined to fix.

FULL JOIN currently is only implementable by mergejoin (if you can
figure out how to do it with a nest or hash join, I'm all ears...).
I guess it's a bug that the planner honors enable_mergejoin = OFF
even when given a FULL JOIN query.  (At least the failure detection
code works, though ;-).)  I'll see what I can do about that.

I'd be inclined *not* to add ORDER BYs just to make regressplans produce
zero diffs in all cases.  The presence of an ORDER BY may cause the
planner to prefer presorted-output plans, thus defeating the purpose
of testing all plan types...
        regards, tom lane