> 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?

Probably, though I don't understand how WAL is related to execution plans.
Ok, it's easy to reproduce - I'll take a look.

Vadim

Wed, 22 Nov 2000 10:42:21 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: regressplans failures 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> I'm guessing this is a variant of the problem Philip Warner reported
>> yesterday.  Probably WAL-related.  Vadim?

> Probably, though I don't understand how WAL is related to execution plans.
> Ok, it's easy to reproduce - I'll take a look.

Could just be a question of a different pattern of table accesses?
Let me know if you want help looking...

			regards, tom lane

Wed, 22 Nov 2000 14:03:29 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: regressplans failures 