Re: regressplans failures

Peter Eisentraut <peter_e(at)gmx(dot)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