Ireneusz Pluta writes:
> - when playing with pg_filedump I noticed that last pages of the table
> are always initially reported as damaged, as they come, then, as newer
> pages get allocated and filled, these initially bad pages "become
> valid", as in the following example repeating the same p
Hello,
I have a server, 8.4.3, where I get intermittent and rather rare cases
of "invalid page headers". Quick search over the pg lists shows a
general advice to "check your hardware". Yes, I need to schedule a
downtime and perform some checks.
However, let me also share with you what I noti
It was CentOS release 3.8 and ext2 (I switched it to ext3 after the
disaster).
HW is HP Array P400, with HP DG146ABAB4 Disks.
Status of one of the disk switched from OK to predictive failure, I guess
the array didn't recognize the failure and didn't park it in time.
Filip
==
Filip Krška wrote:
> I hope, I've solved it.
>
> I found 512 damaged bytes on the 29th 8k page of the pg_type's datafile
> ($PGDATA/base/16390/1247), it was overwritten by text from some log(?!).
Ugh. For the record, what operating system and filesystem are you
using? Oh, the underlying storage
I hope, I've solved it.
I found 512 damaged bytes on the 29th 8k page of the pg_type's datafile
($PGDATA/base/16390/1247), it was overwritten by text from some log(?!).
When I had dropped the whole 8k page (dd of=/tmp/head count=29 bs=8192,
dd of=/tmp/tail skip=30 bs=8192, then cat /tmp/head /t
Filip Krška wrote:
>Hello,
>
> we have (maybe due to temporary Disk Array HW failure, which occurred on
> the same day the pg_dump started to complain - array is now successfully
> rebuilt) problem with consistency of pg_catalog.pg_type table.
Did you solve this problem?
--
Alvaro Herrer
Hello,
we have (maybe due to temporary Disk Array HW failure, which occurred on
the same day the pg_dump started to complain - array is now successfully
rebuilt) problem with consistency of pg_catalog.pg_type table.
pg_dumpall command gives following message:
pg_dump: SQL command failed
p
Hello List,
I'm using postgresql 7.4 on FC4.
When i run following query on postgresql prompt, it gives error.
indse96=# CREATE TEMP TABLE aggregate AS ( SELECT vc_vouchno
,vc_srno,vc_type ,vc_vouchdt,trim(''),vc_descrip, ( CASE WHEN
(vc_dr_cr='D') THEN vc_amount ELS
Robert,
Unfortunatelly yes, that error is suposed to be related with
hardware problems. In my case, a forced reindex sorted the problem for
a while.
smartmontools
badblocks
memtest86
Those are the tools I've used time ago to get the results for bad hardware.
Best wishes,
g.-
On 1/7/07,
Along similar lines to other recent posts I've noticed in the logs some
"Invalid page header in block ### of relation ...". errors. Given that
we have two basically identical s/w setups (ubuntu 6.06 LTS, PG8.1.4)
running on different h/w and only 1 box is reporting these errors and
based on the fee
On Tue, 2007-01-02 at 06:04, [EMAIL PROTECTED] wrote:
> Hi List,
>
> I'm using postgresql 7.4 on FC4 linux.
> i have one table named "purchase". it is working fine since 10 months but
> suddenly from 3-4 days it creates problem.
> when i'm fire a simple "select * from purchase" query on psql promp
Hi List,
I'm using postgresql 7.4 on FC4 linux.
i have one table named "purchase". it is working fine since 10 months but
suddenly from 3-4 days it creates problem.
when i'm fire a simple "select * from purchase" query on psql prompt,it
gives following error:
Invalid page header in block 211 of
Hi everybody,
I have a Postgres Database Server 8.0 in a Windows 2000 Professional.
I need to migrate this server to 8.1.4 or 8.1.5 Posgresql Version, but,
when I execute backup command from pgAdmin III or from a command line (pg_dump
[parameters] ) I get this error:
i
Ian Burrell <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It would probably be worth your while to look at the damaged page with
>> pg_filedump before you zap it. The symptoms of hardware misfeasance and
>> software errors are enough different that you can often tell which
>> theory to believe
Tom Lane wrote:
You can zap just the failed block by turning on "zero_damaged_pages";
that will at least allow you to recover the rest of the table. If you
want to try harder, you could look at the damaged page with pg_filedump
(http://sources.redhat.com/rhdb/) or a similar tool and try to intuit
Ian Burrell <[EMAIL PROTECTED]> writes:
> I get the following error message when doing a select on a table:
> ERROR: invalid page header in block 295 of relation "reported_titles"
> How do I fix this corruption?
You can zap just the failed block by turning on "zero_damaged_pages";
that will at l
I get the following error message when doing a select on a table:
ERROR: invalid page header in block 295 of relation "reported_titles"
I found some messages that said this means a block of this table is
corrupt. I found some suspicious lines in the server log just before:
ERROR: could not acc
Hornyak Laszlo <[EMAIL PROTECTED]> writes:
> I have a problem again, now with PostgreSQL 7.3.4. One of my 1.8 million
> rows tables have damaged, it operated all the day and now it is off, we
> don`t know the reason. When we try to dump or select from it, it says
> 'Invalid page header in block 123
Hi folks!
I have a problem again, now with PostgreSQL 7.3.4. One of my 1.8 million
rows tables have damaged, it operated all the day and now it is off, we
don`t know the reason. When we try to dump or select from it, it says
'Invalid page header in block 12345 in prep'.
Does anybody know how to
19 matches
Mail list logo
