Dan Hrabarchuk
2004-10-12 15:51:04 UTC
Hi
Can someone point me in the right direction on where to start?
I'm not getting the documented behaviour. If this is not the correct
list, I'll ask else where.
Below is the entry quoted from the online manual for 7.3:
ZERO_DAMAGED_PAGES (boolean)
Detection of a damaged page header normally causes PostgreSQL to
report an error, aborting the current transaction. Setting
zero_damaged_pages to true causes the system to instead report a
warning, zero out the damaged page, and continue processing.
This behavior will destroy data, namely all the rows on the
damaged page. But it allows you to get past the error and
retrieve rows from any undamaged pages that may be present in
the table. So it is useful for recovering data if corruption has
occurred due to hardware or software error. You should generally
not set this true until you have given up hope of recovering
data from the damaged page(s) of a table. The default setting is
off, and it can only be changed by a superuser.
-----Forwarded Message-----
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
Can someone point me in the right direction on where to start?
I'm not getting the documented behaviour. If this is not the correct
list, I'll ask else where.
Below is the entry quoted from the online manual for 7.3:
ZERO_DAMAGED_PAGES (boolean)
Detection of a damaged page header normally causes PostgreSQL to
report an error, aborting the current transaction. Setting
zero_damaged_pages to true causes the system to instead report a
warning, zero out the damaged page, and continue processing.
This behavior will destroy data, namely all the rows on the
damaged page. But it allows you to get past the error and
retrieve rows from any undamaged pages that may be present in
the table. So it is useful for recovering data if corruption has
occurred due to hardware or software error. You should generally
not set this true until you have given up hope of recovering
data from the damaged page(s) of a table. The default setting is
off, and it can only be changed by a superuser.
-----Forwarded Message-----
Subject: [ADMIN] zero_damaged_pages having no effect
Date: Mon, 11 Oct 2004 12:44:50 -0700
Hello again.
I have a database on 7.3.4, FreeBSD with corruption. dump & restore is definetly
not an option. Hardware is fine. Registed ECC memory on a SCSI hardware RAID5.
I got the corruption when the file system ran out of space.
I want to simply delete the damaged data and then I can reinsert it from it's
source.
Again, all I want is to delete the damaged data. A dump restore is not an
option.
So I set zero_damaged_pages to true in my postgres.conf.
sam=> select * from pg_settings where name ='zero_damaged_pages';
name | setting
--------------------+---------
zero_damaged_pages | on
(1 row)
When I run a query that hits the damaged area, I was expecting a log message
saying that tuples were being zeroed, and a truncated result in my client.
sam=> SELECT * FROM channeldata where cd_id=6268 and tstamp<'2004-09-20' and
tstamp >'2004-09-15';
PANIC: open of /psql/pg_clog/0C98 failed: No such file or directory
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
Is there some extra trick here? I just want to delete the bad tuples. I can
restore the data from another source.
I really don't care if I need to take the database server down at 2am and use a
hex editor to clean this. I need my boss off my back. Please help me delete
these bad tuples.
Thanks again
Dan Hrabarchuk
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------Date: Mon, 11 Oct 2004 12:44:50 -0700
Hello again.
I have a database on 7.3.4, FreeBSD with corruption. dump & restore is definetly
not an option. Hardware is fine. Registed ECC memory on a SCSI hardware RAID5.
I got the corruption when the file system ran out of space.
I want to simply delete the damaged data and then I can reinsert it from it's
source.
Again, all I want is to delete the damaged data. A dump restore is not an
option.
So I set zero_damaged_pages to true in my postgres.conf.
sam=> select * from pg_settings where name ='zero_damaged_pages';
name | setting
--------------------+---------
zero_damaged_pages | on
(1 row)
When I run a query that hits the damaged area, I was expecting a log message
saying that tuples were being zeroed, and a truncated result in my client.
sam=> SELECT * FROM channeldata where cd_id=6268 and tstamp<'2004-09-20' and
tstamp >'2004-09-15';
PANIC: open of /psql/pg_clog/0C98 failed: No such file or directory
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
Is there some extra trick here? I just want to delete the bad tuples. I can
restore the data from another source.
I really don't care if I need to take the database server down at 2am and use a
hex editor to clean this. I need my boss off my back. Please help me delete
these bad tuples.
Thanks again
Dan Hrabarchuk
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
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