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

From James Hughes
Subject Re: [HACKERS] VACUUM ANALYZE Problem
Date
Msg-id Pine.LNX.3.93.980203093038.30370A-100000@xport.bluewall.com
Whole thread Raw
In response to Re: [HACKERS] VACUUM ANALYZE Problem  ("Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>)
Responses Re: [HACKERS] VACUUM ANALYZE Problem  (Bruce Momjian <maillist@candle.pha.pa.us>)
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.



: (Oh, hell! I got this ERROR while testing subselect and spent so many time
: to fix this problem...)
:
: Vadim



-James


pgsql-hackers by date:

Previous
From: PostgreSQL
Date:
Subject: Re: [HACKERS] Speed boost + Others
Next
From: Andrew Martin
Date:
Subject: Re: [HACKERS] snapshot won't compile on irix6.2