Hi all,
A customer's database has started whining about a busted block:
postgresql-8.4-main.log:2012-10-02 18:51:33 EST ERROR: invalid page header in
block 8429809 of relation base/807305056/950827614
postgresql-8.4-main.log:2012-10-02 18:56:52 EST ERROR: invalid page header in
block 8429809
On Thu, Nov 24, 2005 at 02:59:28PM -0500, Qingqing Zhou wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> wrote
> >
> > At this point I think there's no question that your filesystem is
> > dropping blocks :-(.
>
> It is very interesting to follow this thread. But at this point, can you
> explain more w
On 26/11/05 4:48 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> I deleted the two datasets in mba_data_base that were affected by the empty
>> pages, I also deleted the relevant two rows in measured_bioassay_base... But
>> maybe it didn't do the right thing
Adam Witney <[EMAIL PROTECTED]> writes:
> I deleted the two datasets in mba_data_base that were affected by the empty
> pages, I also deleted the relevant two rows in measured_bioassay_base... But
> maybe it didn't do the right thing with the toast table for these two rows?
Evidently the missing d
On 26/11/05 4:14 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> pg_dump: ERROR: unexpected chunk number 5153 (expected 21) for toast value
>> 245334402
>
>> measured_bioassay_base is always inserted at the same time as mba_data_base
>> (the table where I h
Adam Witney <[EMAIL PROTECTED]> writes:
> pg_dump: ERROR: unexpected chunk number 5153 (expected 21) for toast value
> 245334402
> measured_bioassay_base is always inserted at the same time as mba_data_base
> (the table where I had the problem before) and it has a text field which is
> very large
Could it be faulty hardware?
Run memtest86? Test your drives?
At 10:49 AM 11/26/2005 +, Adam Witney wrote:
Any ideas what is going on here?
Thanks again for any help
Adam
---(end of broadcast)---
TIP 6: explain analyze is your friend
On 24/11/05 5:27 pm, "Adam Witney" <[EMAIL PROTECTED]> wrote:
> On 24/11/05 5:28 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>
>> Adam Witney <[EMAIL PROTECTED]> writes:
>>> Does this help identifying what went wrong?
>>
>> At this point I think there's no question that your filesystem is
>> dropp
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> At this point I think there's no question that your filesystem is
> dropping blocks :-(.
It is very interesting to follow this thread. But at this point, can you
explain more why "there is no question" is file system's fault?
Thanks,
Qingqing
---
On 24/11/05 5:28 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> Does this help identifying what went wrong?
>
> At this point I think there's no question that your filesystem is
> dropping blocks :-(. Might want to check for available kernel updates,
> or
Adam Witney <[EMAIL PROTECTED]> writes:
> Does this help identifying what went wrong?
At this point I think there's no question that your filesystem is
dropping blocks :-(. Might want to check for available kernel updates,
or contemplate changing to a different filesystem.
On 24/11/05 4:42 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> On 24/11/05 4:19 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>>> The question is, can you tell whether any data is actually missing?
>
>> Well each of these datasets are about 20,000 rows each...
Adam Witney <[EMAIL PROTECTED]> writes:
> On 24/11/05 4:19 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> The question is, can you tell whether any data is actually missing?
> Well each of these datasets are about 20,000 rows each... So I can tell
> which one is in (640792,12) and in (640799,1), the
On 24/11/05 4:19 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> If you mean by that, this:
>
>> select * from mba_data_base where ctid = '(640792,12)';
>> select * from mba_data_base where ctid = '(640799,1)';
>
>> Then the data looks normal... Of course e
Adam Witney <[EMAIL PROTECTED]> writes:
> If you mean by that, this:
> select * from mba_data_base where ctid = '(640792,12)';
> select * from mba_data_base where ctid = '(640799,1)';
> Then the data looks normal... Of course everything in between that is now
> blank.
The question is, can you te
On 24/11/05 3:52 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> bugasbase2=# vacuum;
>> WARNING: relation "mba_data_base" page 597621 is uninitialized --- fixing
>
> This is the expected result of what you did.
>
>> WARNING: relation "mba_data_base" page
Adam Witney <[EMAIL PROTECTED]> writes:
> bugasbase2=# vacuum;
> WARNING: relation "mba_data_base" page 597621 is uninitialized --- fixing
This is the expected result of what you did.
> WARNING: relation "mba_data_base" page 640793 is uninitialized --- fixing
> WARNING: relation "mba_data_base
On 24/11/05 2:48 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> Just wanted to clarify, should this not be
>> dd bs=8k seek=7 count=1 conv=notrunc if=/dev/zero of=134401991.4
>
> Looks reasonable.
>
> regards, tom lane
Excellent thanks. I have run it
Adam Witney <[EMAIL PROTECTED]> writes:
> Just wanted to clarify, should this not be
> dd bs=8k seek=7 count=1 conv=notrunc if=/dev/zero of=134401991.4
Looks reasonable.
regards, tom lane
---(end of broadcast)---
TIP 4:
On 23/11/05 10:20 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> Whats the best way to zero the bad block?
>
> Probably dd from /dev/zero, along the lines of
>
> dd bs=8k seek=597621 count=1 conv=notrunc if=/dev/zero of=relation
>
> (check this before you
Adam Witney <[EMAIL PROTECTED]> writes:
> Whats the best way to zero the bad block?
Probably dd from /dev/zero, along the lines of
dd bs=8k seek=597621 count=1 conv=notrunc if=/dev/zero of=relation
(check this before you apply it ;-)). You probably should stop the
postmaster while doing
On 23/11/05 9:55 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> This table is only ever COPY'd to from data files, no updates or deletes, if
>> I could find out which data file this bit comes from I could just reupload
>> that file... Is it possible to tell
Adam Witney <[EMAIL PROTECTED]> writes:
> This table is only ever COPY'd to from data files, no updates or deletes, if
> I could find out which data file this bit comes from I could just reupload
> that file... Is it possible to tell what the data actually is from the data
> I sent?
You might try
On 23/11/05 9:36 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> Thanks for the help Here is the output:
>
>> [EMAIL PROTECTED]:/opt$ dd bs=8k skip=7 count=1 if=134401991.4 | od -x
>> 000
>> *
>> 001 1d
Adam Witney <[EMAIL PROTECTED]> writes:
> Thanks for the help Here is the output:
> [EMAIL PROTECTED]:/opt$ dd bs=8k skip=7 count=1 if=134401991.4 | od -x
> 000
> *
> 001 1d9e 201c 0fa0 0010 000b
> 0010020 0ca6 19fb 1797 0ab4 0
On 23/11/05 8:55 pm, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Adam Witney <[EMAIL PROTECTED]> writes:
>> bugasbase2=# SELECT count(*) from mba_data_base;
>> ERROR: invalid page header in block 597621 of relation "mba_data_base"
>
> Sounds like a data corruption problem :-(. Do you want to pull o
Adam Witney <[EMAIL PROTECTED]> writes:
> bugasbase2=# SELECT count(*) from mba_data_base;
> ERROR: invalid page header in block 597621 of relation "mba_data_base"
Sounds like a data corruption problem :-(. Do you want to pull out that
page and see what's in it? Something like
dd bs=8k
Hi,
I just had this error in my database:
bugasbase2=# SELECT count(*) from mba_data_base;
ERROR: invalid page header in block 597621 of relation "mba_data_base"
Any ideas whats going on? Am a bit worried as this is my production
database.
Thanks for any assistance
Adam
--
This message ha
On Friday 12 November 2004 7:54 am, Martijn van Oosterhout wrote:
> On Thu, Nov 11, 2004 at 04:29:38PM -0700, Steve Crawford wrote:
> > True. I hadn't come up with a good time to get past that 7.4.1 ->
> > 7.4.2 initdb requirement. I guess I'll have to go with the manual
> > method.
>
> IIRC, the i
On Thu, Nov 11, 2004 at 04:29:38PM -0700, Steve Crawford wrote:
> True. I hadn't come up with a good time to get past that 7.4.1 ->
> 7.4.2 initdb requirement. I guess I'll have to go with the manual
> method.
IIRC, the initdb is recommended, but not required. It can be done
without an initdb t
Steve Crawford <[EMAIL PROTECTED]> writes:
>> Could you get a hex dump of that page?
> What is the best method to do this?
There's always "od -x" ... however, if you prefer you can use
pg_filedump from http://sources.redhat.com/rhdb/.
> Also, can I safely drop that table
Not unless you want to
On Thursday 11 November 2004 3:14 pm, Tom Lane wrote:
> Steve Crawford <[EMAIL PROTECTED]> writes:
> > This morning I got bitten by the "SELECT INTO" / "CREATE TABLE
> > AS" from tables without OIDs bug in 7.4.1.
>
> On a production server, you really ought to track bug-fix releases
> a bit more en
Steve Crawford <[EMAIL PROTECTED]> writes:
> This morning I got bitten by the "SELECT INTO" / "CREATE TABLE AS"
> from tables without OIDs bug in 7.4.1.
On a production server, you really ought to track bug-fix releases a
bit more enthusiastically than that :-(. However, I don't see anything
in
This morning I got bitten by the "SELECT INTO" / "CREATE TABLE AS"
from tables without OIDs bug in 7.4.1.
Postmaster killed all the backends and restarted - pg was down for 2
seconds.
This happened two times within a few minute period.
Now I am getting 'invalid page header in block 52979 of re
Hello:
I am a new user of postgresql. I am using postgresql 7.3.4 and I had
inserted about 1.7 million records to a table. When I vacuum / select * from
table, it gets a error message of : Invalid page header in block xxx of
TableA. I check that I still can insert records to the table. But I am
There are a bunch of these in PG's log:
ERROR: Invalid page header in block 14 of
start_items_key
What does it mean? PG seems to be working fine -
anything I need to fix/adjust/worry about?
TIA,
CSN
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved prod
36 matches
Mail list logo
