Re: [HACKERS] VACUUM ANALYZE Problem - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] VACUUM ANALYZE Problem
Date
Msg-id 199802031928.OAA21828@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] VACUUM ANALYZE Problem  (James Hughes <jamesh@interpath.com>)
Responses Re: [HACKERS] VACUUM ANALYZE Problem  (James Hughes <jamesh@interpath.com>)
List pgsql-hackers
>
>
>
> On Tue, 3 Feb 1998, Vadim B. Mikheev wrote:
>
> : 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 ?
> :
>
> THANKS! I'll patch my code and check the other instances.

James, are you going to submit a patch for all the source code?

--
Bruce Momjian
maillist@candle.pha.pa.us

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] VACUUM ANALYZE Problem
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Re: [QUESTIONS] MySQL benchmark page