Tom Lane wrote:
> Bricklen Anderson <bricklen@shaw.ca> writes:
>
>>>Once I recompile the function, I no longer get that message. Is there
>>>anything else that I can check or do to make this stop happening? Or is
>>>this a sign of things to come (possible corruption, etc?)
>
>
> Well, the original error sounds like a disk drive lossage ... you might
> want to think about replacing that drive sometime soon, before it drops
> data from someplace more critical than an index.
>
> In the meantime, look through the pg_proc.prolang column for entries
> that don't match the OID of any row in pg_language. Probably you
> could just UPDATE the ones that are wrong to make them match the OIDs
> of the new rows. I'd suggest a dump and restore of the database
> after you think you have it right, just to make sure everything
> is sane and to get pg_depend back in sync.
>
> regards, tom lane
>
Hi Tom,
Thanks for the tips. I tried to match up pg_proc.prolang and _any_ OID in the
pg_language table. There were NO matches at all. This seemed a bit odd, so I
checked an other db and that one had virtually the same numbers (and they didn't
match either).
=# select distinct prolang from pg_proc;
prolang
---------
12
13
14
17813
63209
63212
63213
63214
(8 rows)
=# select * from pg_language ;
lanname | lanispl | lanpltrusted | lanplcallfoid | lanvalidator | lanacl
----------+---------+--------------+---------------+--------------+---------------
plpgsql | t | t | 17811 | 17812 |
internal | f | f | 0 | 2246 |
c | f | f | 0 | 2247 |
plperlu | t | f | 17808 | 0 |
sql | f | t | 0 | 2248 | {=U/postgres}
plperl | t | t | 17808 | 0 |
(6 rows)
Is it possible that I am misreading the output or your suggestion?