This morning we got the following error from a daily script that
produces a simple largest-table report:
ERROR: could not open relation with OID 597597503
I reran the script and it completed without error.
Our server is running 9.1.15 from PgDg Ubuntu repos and the query run by
the script is:
This morning we got the following error from a daily script that
produces a simple largest-table report:
ERROR: could not open relation with OID 597597503
From a bit of Googling, it seems that Postgres was unable to open the
physical file that contains the relation.
Is it possible that there
On 04/22/2015 02:37 PM, Steve Crawford wrote:
On 04/22/2015 01:25 PM, Adrian Klaver wrote:
If it is of importance, it appears that a temporary table and temporary
index were being created within the same second that the query was run.
Any advice?
WHERE
relkind = 'r'
AND
On 04/22/2015 01:25 PM, Adrian Klaver wrote:
If it is of importance, it appears that a temporary table and temporary
index were being created within the same second that the query was run.
Any advice?
WHERE
relkind = 'r'
AND
relpersistence != 't'
So to confirm. Fix the query and
On 04/22/2015 11:40 AM, Steve Crawford wrote:
This morning we got the following error from a daily script that
produces a simple largest-table report:
ERROR: could not open relation with OID 597597503
I reran the script and it completed without error.
Our server is running 9.1.15 from PgDg
On Fri, Dec 31, 2010 at 11:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think you're missing the point here: there is something about your
standby setup procedure that is causing you to get an inconsistent set
of row states.
For the sake of the archives, the problem turned out to be due to
On Wed, Dec 29, 2010 at 1:53 PM, bricklen brick...@gmail.com wrote:
On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The difference in ctid, and the values of xmin and relfrozenxid,
seems to confirm my suspicion that this wasn't just random cosmic rays.
You did something
On Fri, Dec 31, 2010 at 1:13 PM, bricklen brick...@gmail.com wrote:
On Wed, Dec 29, 2010 at 1:53 PM, bricklen brick...@gmail.com wrote:
On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The difference in ctid, and the values of xmin and relfrozenxid,
seems to confirm my
bricklen brick...@gmail.com writes:
On Wed, Dec 29, 2010 at 1:53 PM, bricklen brick...@gmail.com wrote:
On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You did something on the source DB that rewrote the table with a new
relfilenode (possibly CLUSTER or some form of ALTER
Hi all,
After setting up a warm standby
(pg_start_backup/rsync/pg_stop_backup), and promoting to master, we
encountered an error in the middle of an analyze of the new standby
db. (the standby server is a fresh server)
Source db: PostgreSQL 8.4.2
Standby db: PostgreSQL 8.4.6
...
INFO:
bricklen brick...@gmail.com writes:
After setting up a warm standby
(pg_start_backup/rsync/pg_stop_backup), and promoting to master, we
encountered an error in the middle of an analyze of the new standby
db. (the standby server is a fresh server)
[ relfilenode doesn't match on source and
On Wed, Dec 29, 2010 at 11:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com writes:
After setting up a warm standby
(pg_start_backup/rsync/pg_stop_backup), and promoting to master, we
encountered an error in the middle of an analyze of the new standby
db. (the standby
bricklen brick...@gmail.com writes:
On Wed, Dec 29, 2010 at 11:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What can you tell us about what was happening on the source DB while
the backup was being taken?
The source db has between 1000 and 3000 transactions/s, so is
reasonably volatile. The two
On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
bricklen brick...@gmail.com writes:
On Wed, Dec 29, 2010 at 11:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What can you tell us about what was happening on the source DB while
the backup was being taken?
The source db has
: could not open relation with OID 59132
Hello ,
after google search i havent found any solution or clue for this specific
case:
Background:
Postgresql: 8.3.0
select version();
version
From: Adrian Klaver akla...@comcast.net
To: pgsql-general@postgresql.org
Cc: Postgre Novice postgrenov...@yahoo.com
Sent: Thu, December 10, 2009 10:23:21 PM
Subject: Re: Fw: [GENERAL] ERROR: could not open relation with OID 59132
On Wednesday 09 December
On Thursday 10 December 2009 9:17:47 am Postgre Novice wrote:
At a guess I am thinking it has to do with this:
All constraints on all partitions of the master table are examined during
constraint exclusion, so large numbers of partitions are likely to increase
query planning time
On Wed, Dec 9, 2009 at 4:53 AM, Postgre Novice postgrenov...@yahoo.com wrote:
Hello ,
after google search i havent found any solution or clue for this specific
case:
Background:
Postgresql: 8.3.0
You're missing over a year of updates, and there may well be a bug in
that version that's
Hello ,
after google search i havent found any solution or clue for this specific case:
Background:
Postgresql: 8.3.0
select version();
version
PostgreSQL
Can someone please share some light on this
- Forwarded Message
From: Postgre Novice postgrenov...@yahoo.com
To: pgsql-general@postgresql.org
Sent: Wed, December 9, 2009 5:23:18 PM
Subject: [GENERAL] ERROR: could not open relation with OID 59132
Hello ,
after google search i
OK, I'm getting the above error on one of my fairly new 8.3 production
databases. It happens when I run a query to see the size of my
tables.
SELECT pg_relation_size(c.relfilenode), n.nspname AS schemaname,
c.relname AS tablename, pg_get_userbyid(c.relowner) AS tableowner,
t.spcname AS
Scott Marlowe [EMAIL PROTECTED] writes:
OK, I'm getting the above error on one of my fairly new 8.3 production
databases. It happens when I run a query to see the size of my
tables.
SELECT pg_relation_size(c.relfilenode),
Pretty sure that should be c.oid.
regards,
Scott Marlowe escribió:
OK, I'm getting the above error on one of my fairly new 8.3 production
databases. It happens when I run a query to see the size of my
tables.
SELECT pg_relation_size(c.relfilenode), n.nspname AS schemaname,
c.relname AS tablename, pg_get_userbyid(c.relowner) AS
On Mon, Jul 21, 2008 at 6:07 PM, Tom Lane [EMAIL PROTECTED] wrote:
Scott Marlowe [EMAIL PROTECTED] writes:
OK, I'm getting the above error on one of my fairly new 8.3 production
databases. It happens when I run a query to see the size of my
tables.
SELECT pg_relation_size(c.relfilenode),
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, it's clear that things are already broken before pg_dump started.
You need to show us how to get to this state from a fresh database.
Interestinga new problem maybe, or maybe the same one
...
ERROR:
Alban Hertroys wrote:
On Jun 26, 2008, at 5:41 AM, Rodrigo Gonzalez wrote:
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Craig Ringer wrote:
What platform are you using?
It's running under CentOS 4.4 using ext3, no RAID or LVM.
Server is quad xeon 64 bits 3 GHz
Ugh, I'd
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Tom Lane wrote:
When you say restored from backup, are you talking about a pg_dump
backup, or what?
yes, a pg_dump backup.
There must be something mighty odd in that backup. Would you be willing
to send it to me off-list, so I can try to reproduce
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
pg_dump is working fine now, the problem appear with the pg_buffercache
query...without it I dont notice anything wrong with DBbut of course
there is something wrong. Can be pg_buffercache the problem?
Oh ... looking again at your latest problem
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
pg_dump is working fine now, the problem appear with the pg_buffercache
query...without it I dont notice anything wrong with DBbut of course
there is something wrong. Can be pg_buffercache the problem?
Oh ... looking again at
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Dont know exactly what you mean, if you are talking about the moment
that I receive the error...
No, it's clear that things are already broken before pg_dump started.
You need to show us how to get to this state from a fresh
On Jun 26, 2008, at 5:41 AM, Rodrigo Gonzalez wrote:
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Craig Ringer wrote:
What platform are you using?
It's running under CentOS 4.4 using ext3, no RAID or LVM.
Server is quad xeon 64 bits 3 GHz
Ugh, I'd have liked to think
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, it's clear that things are already broken before pg_dump started.
You need to show us how to get to this state from a fresh database.
Interestinga new problem maybe, or maybe the same one
...
ERROR: relation
PgSQL is returning that error when I open pgdmin and when I run some
queries related to pg_buffercache. Also pg_dump cannot dump the DB.
PgSQL version is 8.3.3 and happened one day after loading the DB there.
Anything that can be done? or I have to restore a backup and put current
data again?
Rodrigo Gonzalez wrote:
PgSQL is returning that error when I open pgdmin and when I run some
queries related to pg_buffercache. Also pg_dump cannot dump the DB.
PgSQL version is 8.3.3 and happened one day after loading the DB there.
What platform are you using?
If Windows:
- Which version
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
PgSQL is returning that error when I open pgdmin and when I run some
queries related to pg_buffercache. Also pg_dump cannot dump the DB.
PgSQL version is 8.3.3 and happened one day after loading the DB there.
That raises a lot of questions about the
Craig Ringer wrote:
Rodrigo Gonzalez wrote:
PgSQL is returning that error when I open pgdmin and when I run some
queries related to pg_buffercache. Also pg_dump cannot dump the DB.
PgSQL version is 8.3.3 and happened one day after loading the DB there.
What platform are you using?
If
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
PgSQL is returning that error when I open pgdmin and when I run some
queries related to pg_buffercache. Also pg_dump cannot dump the DB.
PgSQL version is 8.3.3 and happened one day after loading the DB there.
That raises a lot of
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Craig Ringer wrote:
What platform are you using?
It's running under CentOS 4.4 using ext3, no RAID or LVM.
Server is quad xeon 64 bits 3 GHz
Ugh, I'd have liked to think RHEL4/Centos4 would be more reliable than
that :-(. Still, you might have an
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
It had been working with pgsql 8.1 and 8.2 for 2 years without problems.
Suspicious is that problems started next day I've upgraded to 8.3.
Did you update anything else at the same time?
regards, tom lane
--
Sent via
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Tom Lane wrote:
Did you update anything else at the same time?
No, just postgres was updated
Well, that does start to sound like it could be a PG bug; but no one
else is reporting anything like it. Can you put together a
self-contained test case?
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
It had been working with pgsql 8.1 and 8.2 for 2 years without problems.
Suspicious is that problems started next day I've upgraded to 8.3.
Did you update anything else at the same time?
regards, tom lane
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Tom Lane wrote:
Did you update anything else at the same time?
No, just postgres was updated
Well, that does start to sound like it could be a PG bug; but no one
else is reporting anything like it. Can you put together a
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Craig Ringer wrote:
What platform are you using?
It's running under CentOS 4.4 using ext3, no RAID or LVM.
Server is quad xeon 64 bits 3 GHz
Ugh, I'd have liked to think RHEL4/Centos4 would be more reliable than
that :-(.
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Basically I should reinstall again PG with the same configuration and
wait 1 night. Any log you need or want? anything to do besides doing the
same I did?
Umm ... if I reinstall PG and wait one night, I'm quite sure that
nothing much will happen. You
Tom Lane wrote:
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Basically I should reinstall again PG with the same configuration and
wait 1 night. Any log you need or want? anything to do besides doing the
same I did?
Umm ... if I reinstall PG and wait one night, I'm quite sure that
nothing
Rodrigo Gonzalez [EMAIL PROTECTED] writes:
Dont know exactly what you mean, if you are talking about the moment
that I receive the error...
No, it's clear that things are already broken before pg_dump started.
You need to show us how to get to this state from a fresh database.
Looks like someone or something changed the permissions on the
postgresql folders or files.
Sincerely,
Joshua D. Drake
I've had a look at this file, and postgres has Full Control.
Howard
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
Howard Cole wrote:
Looks like someone or something changed the permissions on the
postgresql folders or files.
Sincerely,
Joshua D. Drake
I've had a look at this file, and postgres has Full Control.
Howard
Further, the system works fine normally. The permissions error appears
to be an
On Friday 23 May 2008 6:02 am, Howard Cole wrote:
Howard Cole wrote:
Looks like someone or something changed the permissions on the
postgresql folders or files.
Sincerely,
Joshua D. Drake
I've had a look at this file, and postgres has Full Control.
Howard
Further, the system
Adrian Klaver wrote:
On Friday 23 May 2008 6:02 am, Howard Cole wrote:
Howard Cole wrote:
Looks like someone or something changed the permissions on the
postgresql folders or files.
Sincerely,
Joshua D. Drake
I've had a look at this file, and postgres has Full Control.
Howard Cole [EMAIL PROTECTED] writes:
Are there likely to be serious integrety implications if Postgres failed to
access/write to this table for whatever reason, or would the transaction be
rolled back.
The command would get an error and the transaction rolled back. I would be
more concerned
Howard Cole wrote:
Adrian Klaver wrote:
On Friday 23 May 2008 6:02 am, Howard Cole wrote:
Howard Cole wrote:
Looks like someone or something changed the permissions on the
postgresql folders or files.
Sincerely,
Joshua D. Drake
I've had a look at this
Can anyone give me a hint how to trace the cause of this error message
in the error log:
ERROR could not open relation 1663/20146/128342: Permission Denied
Running 8.2.7 on W2K3.
Thanks.
Howard Cole.
www.selestial.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
On Fri, 2008-05-23 at 00:08 +0100, Howard Cole wrote:
Can anyone give me a hint how to trace the cause of this error message
in the error log:
ERROR could not open relation 1663/20146/128342: Permission Denied
Running 8.2.7 on W2K3.
Looks like someone or something changed the
Q Master napsal(a):
I get this strange error
Caused by: org.postgresql.util.PSQLException: ERROR: could not open
relation 1663/53544/58374: No such file or directory
How do I recover from it ? Version 8.2 on windows.
I think I had an hardware issue in the past where my box rebooted few
On Wed, May 7, 2008 at 1:50 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
Q Master napsal(a):
I get this strange error
Caused by: org.postgresql.util.PSQLException: ERROR: could not open
relation 1663/53544/58374: No such file or directory
How do I recover from it ? Version 8.2 on
Gurjeet Singh napsal(a):
The query should be
select * from pg_class where relfienode = 58374
Yeah, of course. Thanks
Zdenek
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
I get this strange error
Caused by: org.postgresql.util.PSQLException: ERROR: could not open
relation 1663/53544/58374: No such file or directory
How do I recover from it ? Version 8.2 on windows.
I think I had an hardware issue in the past where my box rebooted few
times I assume this is
We are trying to perform a 'reindex database' and it will fail at
varying points with a message like:
ERROR: could not open relation with OID 587495058
or
ERROR: could not open relation with OID 587603875
When we queried pg_class we got no
Susy Ham [EMAIL PROTECTED] writes:
We are trying to perform a 'reindex database' and it will fail at
varying points with a message like:
ERROR: could not open relation with OID 587495058
or
ERROR: could not open relation with OID 587603875
One final final question: my suspicion is no, but I just want to ask:
this would not affect all inherited tables with bgwriter, would it,
in scenarios where a persistent inherited table gets dropped while a
parent table is being queried? Could this result in a similar
scheduling conflict
Thomas F. O'Connell [EMAIL PROTECTED] writes:
Anyway, if I do a lookup by oid for 94144936 in pg_class, I don't see
it. And, clearly, it's not in $PGDATA/base/32019395.
You should be looking at relfilenode. See
http://www.postgresql.org/docs/8.0/static/storage.html
and/or use oid2name to
The oid in question does not correspond to a relfilenode, and
oid2name -o 94144936 doesn't return anything when run against the
database in question.
Could this be related to temp tables? We use a lot of them in data
imports, and this was a point of discussion on IRC.
Having a limited
Thomas F. O'Connell [EMAIL PROTECTED] writes:
Could this be related to temp tables?
Possibly, given that the table doesn't seem to be there anymore.
Does bgwriter operate on temp tables, and could there exist an edge
condition in which bgwriter might have scheduled a write to disk for
a
On Thu, Jul 14, 2005 at 10:49:56AM -0500, Thomas F. O'Connell wrote:
Does bgwriter operate on temp tables, and could there exist an edge
condition in which bgwriter might have scheduled a write to disk for
a file corresponding to a temp table that was removed by sudden
termination of
Alvaro Herrera [EMAIL PROTECTED] writes:
I suggested that bgwriter may be the culprit, mainly because the log
lines were not preceded by the log_line_prefix as the other lines in the
log. See an extract here: http://rafb.net/paste/results/awxFnY15.html
Hmm, what are the logging configuration
Sorry, I didn't have the evidence about the bgwriter before. It was
based on conjecture on IRC last night and newly gathered evidence
from this morning.
Here's a list of current postgres processes on the box.
postgres 1186 2.8 5.0 437812 417624 ? SJul13 22:37
postgres: writer
Thomas F. O'Connell [EMAIL PROTECTED] writes:
Unfortunately, this is a system where the interloper is superuser
(and, yes, changing this has been a TODO). But even so, I need help
understanding how one backend could access the temp table of another.
You'd have to do it pretty explicitly:
On Jul 14, 2005, at 12:51 PM, Tom Lane wrote:
Thomas F. O'Connell [EMAIL PROTECTED] writes:
Unfortunately, this is a system where the interloper is superuser
(and, yes, changing this has been a TODO). But even so, I need help
understanding how one backend could access the temp table of
So my first instinct was to avoid use of temp tables in this scenario
altogether, but now I'm thinking all I might need to do is unhook the
temp tables from inheritance.
But I just want to raise a basic reliability issu raised in the
nearby Autovacuum loose ends thread issue before I
Thomas F. O'Connell [EMAIL PROTECTED] writes:
does pg_autovacuum as currently written in contrib vacuum temp
tables, and, in 8.0, is this then able (however unlikely) to cause
the sort of error I encountered yesterday?
No, and no, and still no for the integrated version. The
On Thu, Jul 14, 2005 at 04:08:48PM -0500, Thomas F. O'Connell wrote:
So my first instinct was to avoid use of temp tables in this scenario
altogether, but now I'm thinking all I might need to do is unhook the
temp tables from inheritance.
But I just want to raise a basic reliability issu
From this thread, these two bits about PostgreSQL stand out:
I have an old note to myself that persistent write errors could clog
the bgwriter, because I was worried that after an error it would
stupidly try to write the same buffer again instead of trying to make
progress elsewhere. (CVS tip
One other detail: pg_autovacuum is running on this system.
I just noticed this from Tom's Autovacuum loose ends post from
earlier today:
The code does not make a provision to ignore temporary tables.
Although vacuum.c and analyze.c will disregard the request to touch
such tables, it'd
I have a production database where we just encountered the following error:ERROR: could not open relation 1663/32019395/94144936: No such file or directory Here's the output of SELECT version():PostgreSQL 8.0.3 on i686-pc-linux-gnu, compiled by GCC 2.95.4Here's uname -a:Linux hostname 2.6.11.8 #8
I'm developing a habit of being the most frequent replier to my own posts, but anyway: I discovered the meaning of 1663, which is the default tablespace oid.But I still need help with diagnosis and treatment... -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC Strategic Open
76 matches
Mail list logo
