Skip site navigation (1) Skip section navigation (2)

Segmentation fault/compressed data is corrupted.

From: Lukasz Brodziak <lukasz(dot)brodziak(at)gmail(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Segmentation fault/compressed data is corrupted.
Date: 2012-02-10 08:45:19
Message-ID: CAGWYGjVbhet9xd+J6+-v1zgLTsdmymyy20aCLmaBF8ULfLbKLQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
Hi,

I have a problem with one of our clients' dbs while creating a dump he
gets the error mentioned in topic. The full pg_log file is as follows:

LOG: server process (PID 347) was terminated by signal 11: Segmentation fault
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process
exited abnormally and
possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process
exited abnormally and
possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process
exited abnormally and
possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted; last known up at 2012-02-07 08:23:25 CET
LOG: database system was not properly shut down; automatic recovery in progress
LOG: consistent recovery state reached at 0/7B6E82E0
LOG: record with zero length at 0/7B6E82E0
LOG: redo is not required
LOG: database system is ready to accept connections
LOG: autovacuum launcher started


Also during one of the statements he gets:

ERROR: compressed data is corrupt
STATEMENT: select ow.* from ps_opieka_wersja ow join opieka o on
o.id_opi = ow.id_opi join (select pr.id_opi from ps_rozliczenia pr
where COALESCE('1
','-') in ('-',pr.czy_eksport) and pr.status_potw <> 'P' and
pr.kod_jedn is not null and pr.umowa_rok = 2012 and pr.miesiac = '1'
and pr.umowa_nr
= '11/000039/POZ/11/12' group by pr.id_opi) r on r.id_opi = ow.id_opi
where o.czy_eksport and COALESCE(czy_usunieta,'0') = '0' and (
(ow.akt_nr_we
rsji > COALESCE(ow.eksp_nr_wersji,0) or ow.akt_nr_wersji_rozl >
COALESCE(ow.eksp_nr_wersji_rozl,0)) ) union select ow.* from
ps_opieka_wersja ow join pobyt
p on p.id_opi = ow.id_opi join opieka o on ow.id_opi = o.id_opi left
outer join (select pr.id_opi from ps_rozliczenia pr where COALESCE('
1','-') in ('-',pr.czy_eksport) and pr.status_potw <> 'P' and
pr.kod_jedn is not null group by pr.id_opi) r on r.id_opi =
ow.id_opi where o.czy_eksport and r.id_opi is null and
COALESCE(czy_usunieta,'0') = '0' and ( (ow.akt_nr_wersji >
COALESCE(ow.eksp_nr_wersji,0) or ow.akt_n
r_wersji_rozl > COALESCE(ow.eksp_nr_wersji_rozl,0)) ) and
ow.eksp_nr_wersji is not null and 2012 = extract(year from
COALESCE(dt_do,dt_od)) and '1' = e
xtract(month from COALESCE(dt_do,dt_od)) and (p.umowa_nr_nfz = '12345'
and p.umowa_rok_nfz = 2012 or p.umowa_nr_nfz is null and p.umowa_rok
_nfz is null) union select ow.* from ps_opieka_wersja ow join opieka o
on ow.id_opi = o.id_opi where o.czy_eksport and
COALESCE(czy_usunieta,'0') = '1' a
nd ow.eksp_nr_wersji is not null and ( (ow.akt_nr_wersji >
COALESCE(ow.eksp_nr_wersji,0) or ow.akt_nr_wersji_rozl >
COALESCE(ow.eksp_nr_wersji_rozl,0)) ) an
d 2012 in (extract(year from ow.data_wprow),extract(year from ow.data_mod))

This is PG 9.0.0 running on Ubuntu.
-- 
Ɓukasz Brodziak

pgsql-admin by date

Next:From: Greg SpiegelbergDate: 2012-02-10 14:45:22
Subject: 32-bit to 64-bit migration options
Previous:From: Greg WilliamsonDate: 2012-02-07 20:39:48
Subject: Re: postgres 9.0 date aberration in logs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group