On Sun, 15 Mar 1998, Bruce Momjian wrote:
: >
: > This is a multi-part message in MIME format.
: > --------------A99EE0A2D8F4D665C5BF3957
: > Content-Type: text/plain; charset=us-ascii
: > Content-Transfer-Encoding: 7bit
: >
: > James Hughes wrote:
: > >
: > > After poking arround some more, I found that the "vacuum analyze" is
: > > causing problems with the "<" and ">" operators. The "> 0" in the SELECT
: > > for "/d <table>" and "/dS" commands in psql cause the error.
: > >
: > > I verified that any simple query using the "<" or ">" operators fail
: > > with the same message...
: > >
: > > ERROR: fmgr_info: function 0: cache lookup failed
: > >
: > > ...after using the "vacuum analyse" command.
: > > But, only after vacuuming any relation that was created and populated by
: > > me. Vacumming system catalogs poses no problems.
: >
: > Well, I found that this problem was caused by selfuncs.c:gethilokey():
: >
: > static ScanKeyData key[3] = {
: > {0, Anum_pg_statistic_starelid, F_OIDEQ},
: > {0, Anum_pg_statistic_staattnum, F_INT2EQ},
: > {0, Anum_pg_statistic_staop, F_OIDEQ}
: >
: > : skankeys are hardcoded without call to ScanKeyEntryInitialize() =>
: > without initialization of sk_func.fn_oid required, I assume, by
: > new PL support code. Patch for this place follows...
: > One should check all places where ScanKeyData is used.
: > Jan, could you do this ?
: >
: > (Oh, hell! I got this ERROR while testing subselect and spent so many time
: > to fix this problem...)
:
: I assume we can consider this item closed.
:
The problem on my system was fixed by the patch.
-James
