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
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
26 matches
Mail list logo
