On Wed, Jun 29, 2016 at 4:26 PM, Tom Lane wrote:
> Willy-Bas Loos writes:
> > So what i don't get is, -if the above is the case- If pg_dump expects to
> > find an index, it already knows about its existence. Then why does it
> need
> > to look for it again?
>
>
> pg_dump can't tell the index is
Willy-Bas Loos writes:
> So what i don't get is, -if the above is the case- If pg_dump expects to
> find an index, it already knows about its existence. Then why does it need
> to look for it again?
Because what it does is:
BEGIN ISOLATION LEVEL REPEATABLE READ; -- run in a single transaction
On Wed, Jun 29, 2016 at 11:16 AM, Willy-Bas Loos wrote:
> Ah OK. So it needs a lock for the visibility to be registered to the
> transaction, is that it?
>
Wait that doesn't make sense. pg_dump merely describes the table in DDL, so
it doesn't even need access to the index pages. It only needs to
Ah OK. So it needs a lock for the visibility to be registered to the
transaction, is that it?
Willy-Bas Loos writes:
> [ pg_dump sometimes fails with ]
> pg_dump: [archiver (db)] query failed: ERROR: cache lookup failed for
> index 231808363
This wouldn't be too surprising if you're constantly creating and dropping
indexes. There's a small window between where pg_dump starts its
transac
On Tue, Jun 28, 2016 at 7:14 PM, Willy-Bas Loos wrote:
>
> (...)
> Does anyone know what's up?
> --
>
>
oh btw this is postgres 9.3 on debian 7
and londiste 2
--
Willy-Bas Loos
Hi,
I have a londiste consumer database that has some additional user data in
it.
The user data is in schema's with the prefix oz_
Every night we dump those schema's with pg_dump.
About 2-3 times per week cron emails me that something went wrong.
That means that 4-5 day per week, everything works
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
53 AM
To: Pascal Tufenkji
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] cache lookup failed
"Pascal Tufenkji" writes:
> Everything was working fine until a couple of days ago, the database
> is starting to display the following error more and more cache lookup
"Pascal Tufenkji" writes:
> Everything was working fine until a couple of days ago, the database is
> starting to display the following error more and more
> cache lookup failed for relation 1852615815
Hm, what PG version is that? Is 1852615815 anywhere near the range of
existing OIDs in pg_clas
Hi,
I have an application that creates temp tables to speed up the fetching of
the data
Everything was working fine until a couple of days ago, the database is
starting to display the following error more and more
cache lookup failed for relation 1852615815
I noticed that this error ke
Please help
Thanks..
Tamanna
-Original Message-
From: David Fetter [mailto:da...@fetter.org]
Sent: Saturday, July 17, 2010 8:45 PM
To: Merlin Moncure
Cc: tamanna madaan; pgsql-general@postgresql.org
Subject: Re: [GENERAL] cache lookup failed for function 19119
On Thu, Jul 15,
On Thu, Jul 15, 2010 at 10:21:52AM -0400, Merlin Moncure wrote:
> On Thu, Jul 15, 2010 at 2:34 AM, tamanna madaan
> wrote:
> > Hi All
> >
> > I am using postgres-8.1.2 .
> >
> > And getting this error “cache lookup failed for function 19119”.
> >
> > Can anyone please let me know what could have
On Thu, Jul 15, 2010 at 2:34 AM, tamanna madaan
wrote:
> Hi All
>
>
>
> I am using postgres-8.1.2 .
>
> And getting this error “cache lookup failed for function 19119”.
>
> Can anyone please let me know what could have gone wrong.
>
> How can a function go missing . And which function
>
> Its tal
Hi All
I am using postgres-8.1.2 .
And getting this error "cache lookup failed for function 19119".
Can anyone please let me know what could have gone wrong.
How can a function go missing . And which function
Its talkig about ?? its some postgres's internal function or a user
defined func
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-
t happened . . .
LW . . . Lawrence
From: lawrence...@hotmail.com
To: t...@sss.pgh.pa.us
CC: mmonc...@gmail.com; pgsql-general@postgresql.org
Subject: RE: [GENERAL] cache lookup failed for function 72629
Date: Tue, 14 Jul 2009 14:33:19 +
I guess I'll ask on the slony-i mailing list al
I guess I'll ask on the slony-i mailing list also. thanks for your hlep.
LW . . . Lawrence
> To: lawrence...@hotmail.com
> CC: mmonc...@gmail.com; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] cache lookup failed for function 72629
> Date: Tue, 14 Jul 2009 10:18:1
the ordinary in the time
> between.
>
>> Date: Tue, 14 Jul 2009 09:16:05 -0400
>> Subject: Re: [GENERAL] cache lookup failed for function 72629
>> From: mmonc...@gmail.com
>> To: lawrence...@hotmail.com
>> CC: pgsql-general@postgresql.org
>>
>> On
Lawrence Wong writes:
> I had been using Slony-I together with another database on a server on a
> different machine. I had been testing my replication constantly dropping and
> creating my Slony-I tables. This is not out of the ordinary though. I had
> been doing this for many days now.
been doing
this function just a couple minutes earlier to this message and did not do
anything out of the ordinary in the time between.
> Date: Tue, 14 Jul 2009 09:16:05 -0400
> Subject: Re: [GENERAL] cache lookup failed for function 72629
> From: mmonc...@gmail.com
> To: lawrence...
On Tue, Jul 14, 2009 at 9:12 AM, Lawrence Wong wrote:
> I'm sorry. What does 're-applying the function source' mean? and how would
> I do it?
>
> For the 'change to the table' I was talking about, I just tried to do a
> regular update on the table using pgAdmin III.
>
> LW . . . Lawrence
>
well,
0400
> Subject: Re: [GENERAL] cache lookup failed for function 72629
> From: mmonc...@gmail.com
> To: lawrence...@hotmail.com
> CC: pgsql-general@postgresql.org
>
> On Tue, Jul 14, 2009 at 8:23 AM, Lawrence Wong wrote:
> > Hi,
> >
> > I had been using my databas
On Tue, Jul 14, 2009 at 8:23 AM, Lawrence Wong wrote:
> Hi,
>
> I had been using my database for a pretty long time now. It is postgres 8.3
> on Windows 2003 Server. Today I tried to make a change to one of my tables
> and I got this error message:
>
> 'An error has occured: ERROR: cache lookup f
Hi,
I had been using my database for a pretty long time now. It is postgres 8.3 on
Windows 2003 Server. Today I tried to make a change to one of my tables and I
got this error message:
'An error has occured: ERROR: cache lookup failed for function 72629'
I tried stopping the service and sta
This looks like data corruption on that record. Or possibly on
multiple records.
I would:
a) update to the latest bug-fix release of 8.2 asap. I don't see any
fixed bugs which would cause this specific type of error but there are
a lot of them and I could have missed it.
http://www.postgresql.o
Oh, probably found the cause of the sudden restarts:
Jun 23 09:39:13 ph1phys01 genunix: [ID 603404 kern.notice] NOTICE: core_log:
postgres[25239] core dumped: /var/core/core_global.postgres
Jun 23 09:45:56 ph1phys01 genunix: [ID 603404 kern.notice] NOTICE: core_log:
postgres[26455] core dumped: /v
For a certain record in our database I'm getting cache lookup failures
(ERROR: cache lookup failed for type 70385664). And only for one of
the 2 array columns in that record.
The table definition is:
\d inhoudingen
Table "public.inhoudingen"
Column|
c k wrote:
> I got following error while testing some newly created functions.
>
>
> ERROR: cache lookup failed for function 111462
> CONTEXT: PL/pgSQL function "uf_postdoc" line 25 at FOR over
> SELECT rows
>
> ** Error **
>
> ERROR: cache lookup failed for function 111462
>
I got following error while testing some newly created functions.
ERROR: cache lookup failed for function 111462
CONTEXT: PL/pgSQL function "uf_postdoc" line 25 at FOR over SELECT rows
** Error **
ERROR: cache lookup failed for function 111462
SQL state: XX000
Context: PL/pgSQ
"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
"Chris Fischer" <[EMAIL PROTECTED]> writes:
> I'm attempting to write a function which produces a script. The script
> will contain steps necessary to drop/recreate all the functions.
If you're trying to modify functions that are in live use, don't drop
them. Just apply CREATE OR REPLACE FUNCTIO
Env: Windows XP sp2
Version: 8.2.1
I'm attempting to write a function which produces a script. The script
will contain steps necessary to drop/recreate all the functions. I've
got a helper function called 'dropprocsbyname' which takes a schema and
a proc name, finds all matching pg_proc rows an
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
On Mon, 2003-08-18 at 09:44, Martijn van Oosterhout wrote:
> It usually refers to some cached plan referring to a table or object that
> does not exist anymore. Do you have stored procedures that refer to tables
> that are deleted? This includes temporary tables.
>
> So maybe it's only happening w
It usually refers to some cached plan referring to a table or object that
does not exist anymore. Do you have stored procedures that refer to tables
that are deleted? This includes temporary tables.
So maybe it's only happening when a certain stored procedure is executed
twice in the same session?
On Mon, 2003-08-18 at 09:53, Tom Lane wrote:
> Always the same OID, or different ones? Does that OID actually exist in
> pg_class? Can you tell us exactly what SQL command(s) are producing the
> error? (If not, better turn on query logging so you can find out.)
Different OIDs, and they do not
"Jeff Boes" <[EMAIL PROTECTED]> writes:
> What might be the source of this error?
> Cache lookup failed for relation 188485009
> We've been getting these at odd intervals, and they are not reproducible.
Always the same OID, or different ones? Does that OID actually exist in
pg_class? Can you te
What might be the source of this error?
Cache lookup failed for relation 188485009
We've been getting these at odd intervals, and they are not reproducible.
Our setup:
PostgreSQL 7.3.3
Red Hat 7.3
kernel.shmall = 1352914698
kernel.shmmax = 1352914698
shared_buffers = 131072
max_fsm_pag
Suppose you create a function function1 and a trigger
that calls function1. Then you drop function1 and
re-create function1. Now you will find that the
trigger can't see function1's existence. trigger (and
other object too) refeerences functions using OID,
not the function name.
I also feel it b
After create function and trigger, when I update "fams" by delete entry in
table "indi" I get this message :
ERROR: fmgr_info: function 19968: cache lookup failed
Here is an SQL script that makes this happen:
--
create
I am getting the following 'cache lookup failed' error when I try to
update two of the tables in my database through psql. Similiar updates
to three other tables complete successfully. Can anyone give me a hint
on what I'm doing wrong? I'm running PostgreSQL 6.3.2 on Linux 4.1.
splat=> update
63 matches
Mail list logo
