Re: Cache lookup failed for relation, when trying to DROP
От | Mark Gibson |
---|---|
Тема | Re: Cache lookup failed for relation, when trying to DROP |
Дата | |
Msg-id | 388e3729343d41ca4b01fed9c099fe774164101d@cromwell.co.uk обсуждение исходный текст |
Ответ на | Re: Cache lookup failed for relation, when trying to DROP TABLE. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Cache lookup failed for relation, when trying to DROP
|
Список | pgsql-general |
Tom Lane wrote: > Mark Gibson <gibsonm@cromwell.co.uk> writes: > >>I kept getting the following error: >>ERROR: cache lookup failed for relation 4667548 > > > This implies that something someplace still has a link to the table with > that OID. You could do "\set VERBOSITY verbose" so that the code > location the error occurs at gets reported; that might be enough > information to guess what sort of thing is linking to the table. > Or you could just dig through the system catalogs looking for 4667548 > in an OID column that links to pg_class. "\set VERBOSITY verbose" gave me the following: ERROR: XX000: cache lookup failed for relation 4667548 LOCATION: getRelationDescription, dependency.c:1755 and... After sticking 4667548 everywhere an oid can be stuck, I've found an entry in the pg_rewrite table. It's from a rule I added myself, but I dropped it manually, strange that is still lurking around. So, I tried deleting the offending entries from pg_rewrite, and now get: ERROR: XX000: could not find tuple for rule 5173132 LOCATION: getObjectDescription, dependency.c:1669 I'm guessing I'm gonna have to route through pg_catalog for this and delete all deps manually, but it this going to be safe? Would I be better off dumping and restoring the whole database? -- Mark Gibson <gibsonm |AT| cromwell |DOT| co |DOT| uk> Web Developer & Database Admin Cromwell Tools Ltd. Leicester, England.
В списке pgsql-general по дате отправления: