Re: Postgres 9.3 read block error went into recovery mode
| От | Shuwn Yuan Tee |
|---|---|
| Тема | Re: Postgres 9.3 read block error went into recovery mode |
| Дата | |
| Msg-id | CABoYu+my4jHki4Gw0m0PvcqBNk2-0hQEsY+PLdtFzs8E39DkXA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Postgres 9.3 read block error went into recovery mode (Kevin Grittner <kgrittn@ymail.com>) |
| Список | pgsql-general |
Thanks everyone for the reply. So I would conclude it as OpenVZ problem, probably we will run some further check just to make sure no data corruption.
Many thanks again :)
On Thu, Dec 5, 2013 at 12:23 AM, Kevin Grittner <kgrittn@ymail.com> wrote:
Albe Laurenz <laurenz.albe@wien.gv.at> wrote:>> - in OpenVZ container
> Shuwn Yuan Tee wrote:
>
>> We recently experienced crash on out postgres production server.
>> Here's our server environment:
>> ERROR: could not read block 356121 in file "base/33134/33598.2": Bad address
>>
>> LOG: server process (PID 21119) was terminated by signal 7: Bus error> Unless my math is off, a PostgreSQL disk file should not containNot at all; the block number is the logical block number within the
> more than 131072 blocks (1GB / 8KB), so something is whacky
> there.
relation; it determines both the segment to read from (in this case
".2") and the offset into that segment. That all looks fine.Or a VM problem. Personally I have never seen this except in a VM,
> I am no hardware guy, but I believe that a bus error would
> indicate a hardware problem.
and the cause always turned out to be a VM bug. Be sure you are
up-to-date on bug fixes for the software.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-general по дате отправления: