Re: [HACKERS] VACUUM ANALYZE Problem
От | James Hughes |
---|---|
Тема | Re: [HACKERS] VACUUM ANALYZE Problem |
Дата | |
Msg-id | Pine.LNX.3.93.980203093038.30370A-100000@xport.bluewall.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] VACUUM ANALYZE Problem ("Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>) |
Ответы |
Re: [HACKERS] VACUUM ANALYZE Problem
|
Список | 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 по дате отправления: