On Wed, 14 Apr 2004, Tom Lane wrote: > Richard Huxton <dev@archonet.com> writes: > > The error is complaining about a relation that used to have an OID of > > 165058647. This is almost certainly a temporary table. Are there any plpgsql > > functions referring to a temporary table, or do you create, drop, recreate > > tmp_table1 within the same connection? > > The trace suggests this is happening immediately after connect, so the > last part doesn't sound right. It could be a plpgsql function problem, > though the query doesn't look like it invokes any functions. > > What I was wondering about was dangling references within a view, that > is a view referring to a table that no longer exists. (That shouldn't > happen anymore in 7.3 and later, but if this is a pre-7.3 system then > it's possible.) Does this query make use of any views, and if so do the > views change from time to time? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > Sorry i didn't mention my version. It is PostgreSQL 7.3.4. As I metioned there is no function invocted from that query. The view I use to make temporary table was made by query: SELECT advert.id, advert.status1, advert.empid, advert.email, advert.postname1, advert.postname2, advert.industry, advert.obligations1, advert.obligations2, advert.chk_edu, advert.chk_lang, advert.chk_compskills, advert.chk_work, advert.chk_travel , advert.chk_drivlic, advert.chk_auto, advert.chk_worktime, advert.chk_workarea, advert.edu_deg, advert.travel, advert.lica, advert. licb, advert.licc, advert.licd, advert.lice, advert.auto, advert.aquirement1, advert.aquirement2, advert.offer1, advert.offer2, adve rt.fut_all_time, advert.salary1, advert.address1, advert."location", advert.work_time1, advert.work_time2, advert.person1, advert.pe rson2, advert.personpost1, advert.personpost2, advert.phone, advert.fax, advert.web, advert.address2, advert.salary2, advert.time_cr eate, advert.enddate, advert.status2, advert.send_email FROM advert, employer WHERE (((((advert.empid = employer.id) AND (employer.s tatus <> 'B'::bpchar)) AND (employer.act_lidz >= date("timestamp"('today'::text)))) AND (employer.act_no <= date("timestamp"('today' ::text)))) AND ((advert.enddate >= date("timestamp"('today'::text))) AND ((advert.status1 = 'A'::bpchar) OR (advert.status2 = 'A'::b pchar)))); So there is no mucj information you can get out of this, but the only thing is true, that information in view change from time to time. I'v checked everything conected with nonexistent tables and things like that. Everything looks fine. Diging through the source coude reveals me that: src/backend/catalog/dependency.c: elog(ERROR, "cache lookup of relation %u failed", relid); src/backend/catalog/heap.c: elog(ERROR, "cache lookup of relation %u failed", src/backend/catalog/pg_constraint.c: elog(ERROR, "cache lookup of relation %u failed",); src/backend/utils/adt/ruleutils.c: elog(ERROR, "cache lookup of relation %u failed", relid); So bacicaly we have only 4 places, which cane generate errors like that, and all this places refer to HeapTupleIsValid function. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
