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  (James Hughes <jamesh@interpath.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] lock table syntax
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Profile of current backend