pg_class / missing tables

[Wim Kerkhoff]

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 ***@postgresql.org so that your
message can get through to the mailing list cleanly

[Chester Kustarz]

Post by Wim Kerkhoff
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?



---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Tom Lane]

Post by Wim Kerkhoff
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.

Post by Wim Kerkhoff
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?

Post by Wim Kerkhoff
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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ***@postgresql.org so that your
message can get through to the mailing list cleanly

[Wim Kerkhoff]

Post by Tom Lane

Post by Wim Kerkhoff
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.

Post by Tom Lane
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

Post by Tom Lane

Post by Wim Kerkhoff
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.

Post by Tom Lane

Post by Wim Kerkhoff
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.

Post by Tom Lane
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.

Post by Tom Lane
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


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ***@postgresql.org so that your
message can get through to the mailing list cleanly

[Amin]

ya no quiere pertenecer a la lista como de desuscribo...?

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ***@postgresql.org)

[Wim Kerkhoff]

Post by Amin
ya no quiere pertenecer a la lista como de desuscribo...?

Sorry, I have no idea what you're saying...

Wim


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Lee Wu]

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-***@postgresql.org
[mailto:pgsql-admin-***@postgresql.org] On Behalf Of Wim Kerkhoff
Sent: Monday, September 13, 2004 8:31 PM
To: pgsql-***@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 ***@postgresql.org so that your
message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ***@postgresql.org

[Wim Kerkhoff]

Hi Lee,

Thanks for the ideas...

Post by Lee Wu
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=#

Post by Lee Wu
What I did to fix my problem was to vacuum the whole database by login
vacuum;

Didn't make any difference... :-(

Post by Lee Wu
Hope it helps!

Nope :-(

Thanks,

Wim


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match