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
relpersiste
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 do
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 Ubun
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 w
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:
On Fri, Dec 31, 2010 at 11:53 AM, Tom Lane 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
impatience. We were
bricklen writes:
> On Wed, Dec 29, 2010 at 1:53 PM, bricklen wrote:
>> On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane wrote:
>>> You did something on the source DB that rewrote the table with a new
>>> relfilenode (possibly CLUSTER or some form of ALTER TABLE; plain VACUUM
>>> or ANALYZE wouldn't do
On Fri, Dec 31, 2010 at 1:13 PM, bricklen wrote:
> On Wed, Dec 29, 2010 at 1:53 PM, bricklen wrote:
>> On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane wrote:
>>>
>>> The difference in ctid, and the values of xmin and relfrozenxid,
>>> seems to confirm my suspicion that this wasn't just random cosmic
On Wed, Dec 29, 2010 at 1:53 PM, bricklen wrote:
> On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane 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 the source DB that rewrote
On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane wrote:
> bricklen writes:
>> On Wed, Dec 29, 2010 at 11:35 AM, Tom Lane 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
>>
bricklen writes:
> On Wed, Dec 29, 2010 at 11:35 AM, Tom Lane 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 tables in question are not ac
On Wed, Dec 29, 2010 at 11:35 AM, Tom Lane wrote:
> bricklen 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)
>> [
bricklen 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 standby ]
What ca
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: analyzing
On Wed, Dec 9, 2009 at 4:53 AM, Postgre Novice 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 since been fixed. Do
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 cons
From: Adrian Klaver
To: pgsql-general@postgresql.org
Cc: Postgre Novice
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 2009 11:34:39 pm Postgre Novice wrote:
>
On Wednesday 09 December 2009 11:34:39 pm Postgre Novice wrote:
> Can someone please share some light on this
>
>
>
> - Forwarded Message
> From: Postgre Novice
> To: pgsql-general@postgresql.org
> Sent: Wed, December 9, 2009 5:23:18 PM
> Subject: [GENE
Can someone please share some light on this
- Forwarded Message
From: Postgre Novice
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 havent found any
Hello ,
after google search i havent found any solution or clue for this specific case:
Background:
Postgresql: 8.3.0
select version();
version
PostgreSQL 8.3.
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.r
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
"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.
reg
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 tablespace
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 a
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 probl
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 r
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
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
>>
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 "p
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 RHEL
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 fres
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.
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
>
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.
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
> t
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 toget
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, to
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 cas
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 pgsql
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 hav
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
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
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 t
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 vers
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?
Th
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
>
"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 conc
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".
How
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".
> > Howa
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 a
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 subsc
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 p
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 m
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:
http://www.postgresql.org/mailpref/pgsql-g
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 ? Vers
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
time
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 du
"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 58
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 rows
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 fo
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 prob
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
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
"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
isOthe
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 conc
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 an
"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 expli
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 p
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 configurat
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
"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
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 und
"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
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 S
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 2.6.11.8 #8 SMP Tue
76 matches
Mail list logo
