Обсуждение: pg_class / missing tables
I'm trying to recover a database where some tables 'went missing'... Short story: server was rebooted without being shut down properly, upon bootup PostgreSQL (7.4.3) starts fine, but a couple of data tables (along with their associated indexes and sequences) are gone. Other tables are still there. The missing tables aren't listed in \d or in the pg_class table, but according to the sizes of the numbered files in /var/lib/postgres/data/base/142772, the raw files must still be there. What's interested is that if I try: CREATE TABLE missing_table_name (foo int); It does complain that the table already exists... What's happening here? Many thanks, Wim
On Mon, 13 Sep 2004, Wim Kerkhoff wrote: > Short story: server was rebooted without being shut down properly, upon > bootup PostgreSQL (7.4.3) starts fine, but a couple of data tables > (along with their associated indexes and sequences) are gone. Other > tables are still there. Perhaps you have IDE disks that do not fsync properly. I have seen a box that had a bad disk system get into the same condition as well. Perhaps the transaction commit bug fixed in 7.4.4 got you. Perhaps you turned fsync off. In any event, some of your tables and/or indexes are corrupted. You should test your hardware to eliminate that as a concern and upgrade your postgres version. You have backups, right?
Wim Kerkhoff <wim@nyetwork.org> writes:
> Short story: server was rebooted without being shut down properly, upon
> bootup PostgreSQL (7.4.3) starts fine, but a couple of data tables
> (along with their associated indexes and sequences) are gone. Other
> tables are still there.
Hmm. What *exactly* happens when you try
select * from pg_class where relname = 'missing_table_name';
Also, let's see the error log from when you tried to restart the server
after the crash.
> What's interested is that if I try:
> CREATE TABLE missing_table_name (foo int);
> It does complain that the table already exists...
You sure it's not complaining that the type already exists?
> What's happening here?
I'm suspicious that you've got a damaged block of pg_class. It would
make sense that that would take out several rows created at about the
same time, which would explain the fact that the lost items seem closely
related.
If you had *no* other lossage, you might be able to recover by
recreating the tables with the exact same schemas, and then copying the
old data files over these tables' data files. But there are enough
gotchas in this idea that "restore from backup" is probably a better
answer.
regards, tom lane
ya no quiere pertenecer a la lista como de desuscribo...?
I had similar problem before. I was able to select from
the_missig_table.
What I did to fix my problem was to vacuum the whole database by login
psql:
vacuum;
Hope it helps!
-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Wim Kerkhoff
Sent: Monday, September 13, 2004 8:31 PM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] pg_class / missing tables
I'm trying to recover a database where some tables 'went missing'...
Short story: server was rebooted without being shut down properly, upon
bootup PostgreSQL (7.4.3) starts fine, but a couple of data tables
(along with their associated indexes and sequences) are gone. Other
tables are still there.
The missing tables aren't listed in \d or in the pg_class table, but
according to the sizes of the numbered files in
/var/lib/postgres/data/base/142772, the raw files must still be there.
What's interested is that if I try:
CREATE TABLE missing_table_name (foo int);
It does complain that the table already exists...
What's happening here?
Many thanks,
Wim
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Hi Lee,
Thanks for the ideas...
Lee Wu wrote:
>I had similar problem before. I was able to select from
>the_missig_table.
>
>
pmacct=# SELECT * from missing_table;
ERROR: relation "missing" does not exist
pmacct=# select * from missing_table;
ERROR: relation "missing_table" does not exist
pmacct=# \d missing_table
Did not find any relation named "missing_table".
pmacct=# select count(*) from pg_class where relname='missing_table';
count
-------
0
(1 row)
pmacct=# create table missing_table(foo int);
ERROR: type "missing_table" already exists
pmacct=#
>What I did to fix my problem was to vacuum the whole database by login
>psql:
>vacuum;
>
>
Didn't make any difference... :-(
>Hope it helps!
>
>
Nope :-(
Thanks,
Wim
Amin wrote: >ya no quiere pertenecer a la lista como de desuscribo...? > > Sorry, I have no idea what you're saying... Wim
Tom Lane wrote:
>Wim Kerkhoff <wim@nyetwork.org> writes:
>
>
>>Short story: server was rebooted without being shut down properly, upon
>>bootup PostgreSQL (7.4.3) starts fine, but a couple of data tables
>>(along with their associated indexes and sequences) are gone. Other
>>tables are still there.
>>
>>
>
>Hmm. What *exactly* happens when you try
> select * from pg_class where relname = 'missing_table_name';
>
>
No records are returned, just the column headings for that table.
>Also, let's see the error log from when you tried to restart the server
>after the crash.
>
>
2004-09-13 13:17:55 [1526] LOG: database system was interrupted at
2004-09-13 12:14:08 PDT
2004-09-13 13:17:55 [1526] LOG: invalid magic number 0000 in log file
40, segment 199, offset 3670016
2004-09-13 13:17:55 [1526] LOG: invalid primary checkpoint record
2004-09-13 13:17:55 [1526] LOG: using previous checkpoint record at
28/C4720CB8
2004-09-13 13:17:55 [1526] LOG: redo record is at 28/C3009E78; undo
record is at 0/0; shutdown FALSE
2004-09-13 13:17:55 [1526] LOG: next transaction ID: 394565; next OID:
25070992
2004-09-13 13:17:55 [1526] LOG: database system was not properly shut
down; automatic recovery in progress
2004-09-13 13:17:55 [1526] LOG: redo starts at 28/C3009E78
2004-09-13 13:18:13 [1526] LOG: invalid magic number 0000 in log file
40, segment 199, offset 0
2004-09-13 13:18:13 [1526] LOG: redo done at 28/C6FFFF84
2004-09-13 13:18:25 [1526] LOG: recycled transaction log file
"00000028000000C3"
2004-09-13 13:18:25 [1526] LOG: recycled transaction log file
"00000028000000C5"
2004-09-13 13:18:25 [1526] LOG: recycled transaction log file
"00000028000000C4"
2004-09-13 13:18:25 [1526] LOG: database system is ready
>
>
>>What's interested is that if I try:
>>CREATE TABLE missing_table_name (foo int);
>>It does complain that the table already exists...
>>
>>
>
>You sure it's not complaining that the type already exists?
>
>
Ahaha... you're right. No entry in pg_class, but there is an entry in
pg_type.
/*
SELECT typname, typrelid from pg_type where typname like
'missing_table_name';
typname | typrelid
-----------------+----------
missing_table_name | 142777
*/
And, the typrelid matches the filenames in the $PGDATA/base/142772/
directory! Nice.
>>What's happening here?
>>
>>
>
>I'm suspicious that you've got a damaged block of pg_class. It would
>make sense that that would take out several rows created at about the
>same time, which would explain the fact that the lost items seem closely
>related.
>
>
This makes sense - thanks for the explanation.
>If you had *no* other lossage, you might be able to recover by
>recreating the tables with the exact same schemas, and then copying the
>old data files over these tables' data files.
>
Ok. I'm going to give that a try.
>But there are enough
>gotchas in this idea that "restore from backup" is probably a better
>answer.
>
> regards, tom lane
>
>
Yea... Thanks for the help.
Wim