Re: cache lookup of relation 165058647 failed - Mailing list pgsql-general

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.