Hi,
The harddrive on which i had linked pg_xlog
has been lost. I have all other folders except that
which are in a seperate drive are present.
Can i get my data back using pg_resetxlog ?
Any Help will be greatly appreciated.
Regds
Mallah.
---(end of
Lee Wu [EMAIL PROTECTED] writes:
We have table is database which cannot be displayed by
either \d, or \dt or pg_class.
But we can select, DML on it.
You could not possibly be selecting from it if it's not in pg_class.
I expect this is pilot error on your part, but there's not enough info
here
Title: RE: [ADMIN] table not shown
Could this be a schema issue?
-Original Message-
From: Lee Wu [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 15, 2004 6:56 AM
To: Tom Lane
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] table not shown
Here is screen shot:
psql
Password:
Welcome
Rajesh Kumar Mallah wrote:
Hi,
The harddrive on which i had linked pg_xlog
has been lost. I have all other folders except that
which are in a seperate drive are present.
Can i get my data back using pg_resetxlog ?
Give it a try: create the xlog folder again and run pg_resetxlog.
Title: RE: [ADMIN] table not shown
Thank you.
But this is not my case:
mxl=# select relname from pg_class where
lower(relname) = 'mxl_quar_process'; select * from mxl_quar_process limit 1;
relname
-
(0 rows)
quar_id | customer_id | domain_id | user_id
| host_id |
do a vacuum full on template1 and see if it reappears.
Robert Treat
On Tue, 2004-06-15 at 13:10, Lee Wu wrote:
Hi Duane,
It seems it is not:
mxl=# show search_path;
search_path
--
$user,public
(1 row)
mxl=# select current_schema(), current_user;
Lee Wu [EMAIL PROTECTED] writes:
Here is screen shot:
mxl=# select * from pg_class where relname = 'mxl_quar_process';
[ no rows ]
mxl=# select * from mxl_quar_process limit 1;
[ data ]
That's just plain bizarre.
I'm wondering about corruption of the indexes on pg_class --- though I'd
Thanks Tom!
Here is result:
mxl=# select * from pg_catalog.pg_class where relname =
'mxl_quar_process';
relname | relnamespace | reltype | relowner | relam | relfilenode |
relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex |
relisshared | relkind | relnatts | relchecks |
pg 7.4.2 on RH 7.3
Hi,
Am getting Out of memory error and pgSql is getting killed when running the
following statement in psql:
insert into tableA
select * from tableB
where testdate = '2000-01-01' and testdate = '2002-12-31'
TableB contains about 120 million records. The insert/select affects
Lee Wu [EMAIL PROTECTED] writes:
Here is result:
mxl=# select * from pg_catalog.pg_class where relname =
'mxl_quar_process';
[ still no rows ]
Okay. I was wondering about bizarre ideas like a non-system table named
pg_class, but that seems ruled out now. I think you're down to the
REINDEX.
I think data dictionary got corrupted:
mxl=# \d mxl_user_wbl
Table public.mxl_user_wbl
Column | Type | Modifiers
-+--+---
-
user_id | integer
I could start the postmaster after doing
pg_resetxlog .
The docs tell that a dump reload of the database should be done.
I am trying to do that by starting a new postmaster in a seprate port
and using pg_dumpall
while i do that i get some minor errors like
ALTER USER arvind SET search_path TO
Hi,
Just wondering if we can bring up PG after we stop it and
reindex database in the case DD corrupted?
That is our worry.
Thanks,
-Original Message-
From: Lee Wu
Sent: Tuesday, June 15, 2004 2:25 PM
To: 'Tom Lane'
Cc: [EMAIL PROTECTED]
Subject: RE: [ADMIN] table not shown
I think
Hey folks,
I am working on a rather small, simple database. I'm running 7.3.5 on
an OpenBSD 3.5-STABLE machine (1.3GHz, 512M RAM, IDE drive using UDMA-5).
I am parsing and storing emails, so I have a lot of character string
data to worry about. In one particular table, I have 26 columns
On Tue, 2004-06-15 at 18:58, C. Bensend wrote:
Hey folks,
I am working on a rather small, simple database. I'm running 7.3.5 on
an OpenBSD 3.5-STABLE machine (1.3GHz, 512M RAM, IDE drive using UDMA-5).
I am parsing and storing emails, so I have a lot of character string
data to
ow [EMAIL PROTECTED] writes:
insert into tableA
select * from tableB
where testdate = '2000-01-01' and testdate = '2002-12-31'
What's happening is that pgSql gradually takes all (well, almost) physical and
swap memory and then, I think, is getting killed by the kernel.
1) Is this normal?
Were those fields populated just like the varchar fields? If not, then
the test proves little. If so, I find it hard to believe that char(x)
would be any faster than varchar. They're all handled about the same.
Hi Scott,
Yes, the new table was populated from the data from the original,
C. Bensend [EMAIL PROTECTED] writes:
So, I went ahead and created an exact copy of this table, with the
exception of creating all character columns as type char(), not varchar().
I was pondering if making PostgreSQL worry about the varying lengths
by using varchar was the problem...
The above
C. Bensend [EMAIL PROTECTED] writes:
So, I went ahead and created an exact copy of this table, with the
exception of creating all character columns as type char(), not
varchar().
I was pondering if making PostgreSQL worry about the varying lengths
by using varchar was the problem...
The
C. Bensend [EMAIL PROTECTED] writes:
The above transformation is a guaranteed loser in Postgres.
By transformation, do you mean the varchar() - char() change?
Right. The only thing that will do for you is waste space with padding
blanks. The performance improvement you saw was due to
Hi Benny,
What happens if you recreate the table using varchar? I mean use the same
procedure yoused to create the table with char, but leave the definitions as
varchar.
Personally, I can't see any logical reason for char being faster. The
problem is the size of the row, each row spans multiple
Right. The only thing that will do for you is waste space with padding
blanks. The performance improvement you saw was due to something else,
which I theorize is not having to waste time reading dead space.
Since you obviously doubt this assertion, try the same experiment except
load the
Or do I just need to vacuum more often? I _did_ try a vacuum before
asking the list for help, but it didn't give any improvement (just a
vacuum analyze).
vacuum analyse allows dead space to be re-used, but doesn't compact the
table, you need vacuum analyse full for that.
I'm not sure how
23 matches
Mail list logo
