Re: [HACKERS] VACUUM ANALYZE Problem

James Hughes <jamesh@interpath.com>

From: James Hughes <jamesh@interpath.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>
Cc: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>, hackers@postgreSQL.org, wieck@sapserv.debis.de
Date: 1998-03-20T02:17:36Z
Lists: pgsql-hackers

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