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

From Vadim B. Mikheev
Subject Re: [HACKERS] VACUUM ANALYZE Problem
Date
Msg-id 34D6FAD3.E165A27C@sable.krasnoyarsk.su
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>)
Re: [HACKERS] VACUUM ANALYZE Problem  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] VACUUM ANALYZE Problem  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
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...)

Vadim

Attachment

pgsql-hackers by date:

Previous
From: James Hughes
Date:
Subject: Re: [HACKERS] VACUUM ANALYZE Problem
Next
From: "Oliver Elphick"
Date:
Subject: Re: [HACKERS] (: JDBC+(Sun ~3:pm MST) CVS :) -also question about regression tests