Thank you, Tom!
Recently, as I wanted to drop a schema (PG 8.2), I had to wade through a
number of such messages and keep dropping rows in the pg_dependency table
with the OID specified in the messages. When I was finally able to drop the
schema, I wanted to drop the user (who previously owned the
David Clymer wrote:
> The SERIALIZABLE isolation mode is being used in 9.0, and
> REPEATABLE READ in 9.2, which should be the same thing, correct
> (eg. 9.0 serializable ~ 9.2 repeatable read)?
Correct.
In 9.0 SERIALIZABLE and REPEATABLE READ are exactly same. In 9.1
and later REPEATABLE READ
2013/2/11 David Clymer
> On Mon, Feb 11, 2013 at 1:13 PM, David Clymer > wrote:
>
>> On Mon, Feb 11, 2013 at 12:47 PM, Pavel Stehule
>> wrote:
>>
>>> 2013/2/11 Tom Lane :
>>> > David Clymer writes:
>>> >> I've been seeing the following error in one database of ours:
>>> >> "cache lookup fail
On Mon, Feb 11, 2013 at 1:13 PM, David Clymer
wrote:
> On Mon, Feb 11, 2013 at 12:47 PM, Pavel Stehule
> wrote:
>
>> 2013/2/11 Tom Lane :
>> > David Clymer writes:
>> >> I've been seeing the following error in one database of ours:
>> >> "cache lookup failed for relation 7640518"
>> >
>> > Alw
On Mon, Feb 11, 2013 at 12:47 PM, Pavel Stehule wrote:
> 2013/2/11 Tom Lane :
> > David Clymer writes:
> >> I've been seeing the following error in one database of ours:
> >> "cache lookup failed for relation 7640518"
> >
> > Always the same OID, or does it change?
> >
> >> The SQL that apparen
On Mon, Feb 11, 2013 at 12:20 PM, Tom Lane wrote:
> David Clymer writes:
> > I've been seeing the following error in one database of ours:
> > "cache lookup failed for relation 7640518"
>
> Always the same OID, or does it change?
>
It appears that almost all instances reference a different OI
=?UTF-8?B?UMOpdGVyIEtvdsOhY3M=?= writes:
> I'm confused by the error message. Is a cache miss an error condition?
Well, this isn't a "cache miss", it's more of a "there's no such OID in
the pg_class catalog" condition. Normally you see something more
user-friendly; but in the case of going to re
2013/2/11 Tom Lane :
> David Clymer writes:
>> I've been seeing the following error in one database of ours:
>> "cache lookup failed for relation 7640518"
>
> Always the same OID, or does it change?
>
>> The SQL that apparently triggers this is:
>>drop table if exists ns_e5461ae570429d0b7863
I'm confused by the error message. Is a cache miss an error condition?
Thanks
Peter
On Feb 11, 2013 6:22 PM, "Tom Lane" wrote:
> David Clymer writes:
> > I've been seeing the following error in one database of ours:
> > "cache lookup failed for relation 7640518"
>
> Always the same OID, or do
David Clymer writes:
> I've been seeing the following error in one database of ours:
> "cache lookup failed for relation 7640518"
Always the same OID, or does it change?
> The SQL that apparently triggers this is:
>drop table if exists ns_e5461ae570429d0b7863cce9ef4d4ead;
> Unfortunately,
I've been seeing the following error in one database of ours:
"cache lookup failed for relation 7640518"
The SQL that apparently triggers this is:
drop table if exists ns_e5461ae570429d0b7863cce9ef4d4ead;
Unfortunately, manual attempts to reproduce the issue have failed. In
normal operatio
Keaton Adams writes:
> Any ideas why we would be receiving this cache lookup failed message?
> PostgreSQL 8.3.7 64 bit, RHEL 5 64 bit OS
> [ query applying pg_table_is_visible() to most of pg_class ]
Is it repeatable, or just something that shows up occasionally with
different OIDs mentioned? I
Any ideas why we would be receiving this cache lookup failed message?
PostgreSQL 8.3.7 64 bit, RHEL 5 64 bit OS
Linux hostname.net 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64
x86_64 x86_64 GNU/Linux
<2010-02-07 08:05:36 MST>ERROR: cache lookup failed for relation 391262678
<2010-
"Wei Wu" <[EMAIL PROTECTED]> writes:
> Basically, we have a table X, trying to drop
> it would result an error message below:
> cache lookup failed for relation X
You've got missing catalog rows, apparently.
> I am using PgAdmin and I can still view the schema of this table, but
> any opera
I found some posts be developers discussing this issue last Jan. and Nov.. See
link below.
http://search.postgresql.org/search?m=1&q=cache+lookup+failed+for+relation&l=&d=&s=
But have not been able to find any suggestion on how an end user can use to get
around this problem. Basically, we have
I found some posts be developers discussing this issue last Jan. and Nov..
See link below.
http://search.postgresql.org/search?m=1&q=cache+lookup+failed+for+relation
&l=&d=&s=
But have not been able to find any suggestion on how an end user can use
to get around this problem. Basically, we ha
On 10/15/2004 4:20 AM, Mark Gibson wrote:
Andrew Sullivan wrote:
On Wed, Oct 06, 2004 at 05:25:58PM +0100, Mark Gibson wrote:
I had to remove Slony's schema manually as I was having problems
with it. I was in the process of removing all Slony related stuff,
and all my slave tables when this problem
Andrew Sullivan wrote:
On Wed, Oct 06, 2004 at 05:25:58PM +0100, Mark Gibson wrote:
I had to remove Slony's schema manually as I was having problems
with it. I was in the process of removing all Slony related stuff,
and all my slave tables when this problem occurred, and was going to
start again fr
On Wed, Oct 06, 2004 at 05:25:58PM +0100, Mark Gibson wrote:
> I had to remove Slony's schema manually as I was having problems
> with it. I was in the process of removing all Slony related stuff,
> and all my slave tables when this problem occurred, and was going to
> start again from scratch.
Di
Tom Lane wrote:
Mark Gibson <[EMAIL PROTECTED]> writes:
Right then, I think I've got this sorted,
DROP TABLE worked after a swift:
DELETE FROM pg_depend WHERE objid = 5173132;
There's something awfully flaky going on here. The system should never
have let you get into this state in the first plac
Mark Gibson <[EMAIL PROTECTED]> writes:
> Right then, I think I've got this sorted,
> DROP TABLE worked after a swift:
> DELETE FROM pg_depend WHERE objid = 5173132;
There's something awfully flaky going on here. The system should never
have let you get into this state in the first place: the ent
Mark Gibson wrote:
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?
Right then, I think I've got this sorted,
DROP TABLE worked after a swift:
DELETE FROM pg_d
Tom Lane wrote:
Mark Gibson <[EMAIL PROTECTED]> 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
Mark Gibson <[EMAIL PROTECTED]> 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 g
Hello,
I've just encountered a problem that I don't know how to deal with.
After having a play with SlonyI, I dropped the entire slony cluster
schema, and then tried to drop a schema which held some slave tables
for the slony cluster.
I kept getting the following error:
ERROR: cache lookup faile
25 matches
Mail list logo
