Re: [HACKERS] VACUUM ANALYZE Problem
От | James Hughes |
---|---|
Тема | Re: [HACKERS] VACUUM ANALYZE Problem |
Дата | |
Msg-id | Pine.LNX.3.93.980319211059.12982A-100000@xport.bluewall.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] VACUUM ANALYZE Problem (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: