Re: [HACKERS] VACUUM ANALYZE Problem
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] VACUUM ANALYZE Problem |
Дата | |
Msg-id | 199803160440.XAA21987@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] VACUUM ANALYZE Problem ("Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>) |
Ответы |
Re: [HACKERS] VACUUM ANALYZE Problem
|
Список | pgsql-hackers |
> > 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. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: