From: | Dan Langille <dan(dot)langille(at)gmail(dot)com> |
---|---|
To: | Torello Querci <tquerci(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Luca Ferrari <fluca1978(at)infinito(dot)it>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Problem creating index |
Date: | 2013-08-28 10:52:25 |
Message-ID: | A8BA2836-6081-43AC-BE00-18B15BD635F7@langille.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Same version of DB for dump & restore? If not, was the dump done via the pg_dump from the newer version. If not, please do that.
--
Dan Langille
http://langille.org/
On Aug 28, 2013, at 2:56 AM, Torello Querci <tquerci(at)gmail(dot)com> wrote:
> Interesting .....
>
> while trying to restore the database on the same machine as different database I get this error message:
>
> ERROR: date/time field value out of range: "20016009:50:37.927936"
>
> Since I get this data from a database dump obtained with "pg_dump" on the same hardware I suppose that can to be two possibility:
>
> - postgresql bug somewhere
> - hardware problem that caused data corruption
>
> Since the dump file is 11G is not so easy to handle ....
> I think that this is not related with create index problem since this field is not used by this index and increase maintenance memory had worked.
>
> I'll fix it and go ahead in maintenance_work_mem test for index creating.
>
>
> Best Regards
>
>
> 2013/8/27 Torello Querci <tquerci(at)gmail(dot)com>
>>
>>
>>
>> 2013/8/26 Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
>>> On Mon, Aug 26, 2013 at 10:01 AM, Torello Querci <tquerci(at)gmail(dot)com> wrote:
>>> > Ok,
>>> >
>>> > now create index is finished using maintenance_work_mem=100MB.
>>> >
>>> > Thanks to all.
>>> >
>>> > I suppose that an error message more clear can help.
>>>
>>> Unfortunately, since no one knows what the real problem is, we can't
>>> make the message more clear. Something that is never supposed to
>>> happen has happened.
>>>
>>> One thing you could do is set log_error_verbosity to verbose.
>>>
>>> It seems like the most likely cause is flaky hardware, either memory
>>> or hard-drive. In which case, your database is in serious danger of
>>> irrecoverable corruption.
>>>
>>> Is it reproducible that if you lower the maintenance_work_mem you get
>>> the error again, and if you raise it the error does not occur?
>>>
>>
>> I'll try to restore the database on the same hw but different DB using differente maintenance_work_mem end verbosity and I'll posted the result here, if can help to improve the error message.
>>
>>
>> Cheers, Torello
>>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Torello Querci | 2013-08-28 11:08:51 | Re: Problem creating index |
Previous Message | shanmugavel muthuvel | 2013-08-28 10:05:38 | virtualxid,relation lock |