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 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
"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
39 matches
Mail list logo
