"Sandeep Agarwal" <sandeepagarwal.1980@gmail.com> writes:
> After googlging about the issue and checking the pg_catalogs i found
> that pg_operator is having two null records
> # /usr/local/pgsql/bin/psql -U postgres -d ihm
> ihm=# select * from pg_operator where oprnamespace is null;
> oprname | oprnamespace | oprowner | oprkind | oprcanhash | oprleft |
> oprright | oprresult | oprcom | oprnegate | oprlsortop | oprrsortop |
> oprltcmpop | oprgtcmpop | oprcode | oprrest | oprjoin
>
---------+--------------+----------+---------+------------+---------+----------+-----------+--------+-----------+------------+------------+------------+------------+---------+---------+---------
> | | | | | |
> | | | | | |
> | | | |
> | | | | | |
> | | | | | |
> | | | |
> (2 rows)
You've got a badly corrupted table there :-( pg_filedump might yield
some clues as to what happened, but what you'll probably ultimately
have to do is try to copy the pg_operator data over from an undamaged
database in the same cluster. I'd suggest a dump and reload as soon
as you can get a clean pg_dump --- with something like this, I always
wonder what else has been tromped on.
As far as preventing it from happening again:
* are you on the latest minor release for your version of Postgres?
(This doesn't look like any bug I know of, but it's still good advice)
* are you running an up-to-date kernel?
* try running memory and disk diagnostics to see if you've got
flaky hardware.
If I had to bet with no more info, I'd bet on kernel bugs first and
flaky RAM second.
regards, tom lane
