Re: ERROR: XX000: cache lookup failed for type 75083631

From: Jan Beseda <besedajohn(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: ERROR: XX000: cache lookup failed for type 75083631
Date: 2022-04-20 20:07:38
Message-ID: CAHaN6DaDeVUZtTZ8KEA_WY0=k_NuTkYqoOmw7ebJQ7k3fbq0+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Tom, Thanks for getting me directions for debugging, but it seems the
devops team fully restored the system snapshot on corrupted instance for
me. If it occurs again I'll reopen/write you as reply here if that's ok.

Cheers, Jan

čt 14. 4. 2022 v 19:24 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Jan Beseda <besedajohn(at)gmail(dot)com> writes:
> > I'm having an issue with dropping a view as shown below:
>
> > DROP VIEW access_group_view;
> > ERROR: XX000: cache lookup failed for type 75083631
> > LOCATION: format_type_internal, format_type.c:152
>
> Does the behavior change if you say CASCADE?
>
> The fact that it's failing in format_type() implies that something is
> trying to print the name of a type, which doesn't seem like a main-line
> activity for DROP VIEW. I am suspicious that pg_depend shows this type
> OID as dependent for some reason on this view, and that the message
> that it was trying to print was complaining about how that dependency
> existed and that you'd need to say CASCADE to make it take. However,
> since format_type() fails, the type OID must not really exist anymore,
> implying that the pg_depend entry is orphaned.
>
> That raises a different set of questions about how it got to be that way.
> But at any rate, what I'd suggest is
>
> 1. Verify that the type OID is wrong:
> select * from pg_type where oid = 75083631;
> If that finds a row then we've got a whole other set of issues.
> (BTW, if you want to be really sure, forcing a seqscan for this
> query or reindexing pg_type could be advisable.)
>
> 2. Check for bogus entries in pg_depend:
> select * from pg_depend where objid = 75083631;
> select * from pg_depend where refobjid = 75083631;
>
> 3. If there's just one hit in pg_depend then it's probably
> safe to delete that row.
>
> regards, tom lane
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ravi Krishna 2022-04-20 20:31:01 Re: Are stored procedures/triggers common in your industry
Previous Message Tim Clarke 2022-04-20 19:51:44 Re: Are stored procedures/triggers common in your industry