> > It would help to know if it is the cache, or an index problem. It is
> > sometimes hard to determine because the cache often uses the indexes
> > to load the cache.
> > Can someone step through a bad entry, and tell me where it is failing?
> > If it is in the executor, it probably is an index. EXPLAIN does show
> > what indexes are involved. Are several indexes failing, or just one?
>
> I'm not sure how to "step through a bad entry" for this case. Just
> haven't done it before, and have never used gdb on the backend. That may
> explain why I've got so many debugging print statements :)
Oh, you are missing so much fun. Just compile with -g, and run gdb as
the postgres user, and do 'run -D /usr/local/pgsql/data test' and you
get a nice prompt. You are not using the postmaster, and are not using
the shared buffer cache, but this is usually not a problem. Give you
the ability to do all sorts of things. 's' steps into functions, 'n'
steps over functions, 'break' stops at certain functions or line
numbers.
>
> I believe that in at least some cases the index itself is damaged. If it
> were just problems _updating_ the cache, then stopping and restarting
> all frontends and backends might fix the problem, at least for the first
> query. That doesn't eliminate the possibility that it is a problem with
> the cache as it is first built though.
>
OK, let me suggest something. Create a table, make it int4, stuff some
values in there, create an index, do a vacuum, and make sure the index
is being used using EXPLAIN. Then, see if you can retrieve the values
using the index.
This should show if the problem exists external to pg_class. I believe
you will find that it works fine, so it must be the system indexes that
are at fault. Are other system indexes affected, or only pg_class
indexes?
--
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)
