Обсуждение: PG 8.3beta3 Segmentation Fault during Database Restore

Hi folks,

I've been trying to test a backup/restore of our production database
(26GB on disk) using PG 8.2.4 as backup and PG 8.3beta3 for the restore.

FIRST TRY:
     pg_dump (v8.3beta3)  --format=c    the PG 8.2.4 database  .... OK
     pg_restore  into a brandnew PG 8.3beta3 database  ....
Segmentation fault after ~10min
     From the serverlog:
     2007-11-27 11:03:27 CET [7133] LOG:  server process (PID 7337)
was terminated by signal 11: Segmentation fault
     2007-11-27 11:03:27 CET [7235] CONTEXT:  COPY login_session,
line 9210986

SECOND TRY:
     Increased the loglevel to DEBUG1
     pg_dump (v8.2.4)  --format=p    the PG 8.2.4 database into an
ASCII file (31 GB)  .... OK
     psql-restore into a brandnew PG 8.3beta3 database  ....
Segmentation fault after ~2hours
     From the serverlog:
2007-11-27 15:56:38 CET [15833] STATEMENT:  CREATE INDEX
login_session_promotion_id ON login_session USING btree (promotion_id);
2007-11-27 15:56:38 CET [15833] ERROR:  concurrent insert in progress
2007-11-27 15:56:38 CET [15833] STATEMENT:  CREATE INDEX
login_session_web_site_id ON login_session USING btree (web_site_id);
2007-11-27 15:56:50 CET [21670] DEBUG:  autovacuum: processing
database "gaia"
2007-11-27 15:57:58 CET [15726] LOG:  server process (PID 15833) was
terminated by signal 11: Segmentation fault
2007-11-27 15:57:58 CET [15726] LOG:  terminating any other active
server processes

What could be the cause of this problem? Is it a bug or my fault?
The postgres.crash.log is enclosed.

Thanks,
Rudolf VanderLeeden
Logicunited GmbH
Germany
vanderleeden@logicunited.com

Rudolf van der Leeden wrote:
> Hi folks,
>
> I've been trying to test a backup/restore of our production database 
> (26GB on disk) using PG 8.2.4 as backup and PG 8.3beta3 for the restore.
>
> FIRST TRY:
>     pg_dump (v8.3beta3)  --format=c    the PG 8.2.4 database  .... OK
>     pg_restore  into a brandnew PG 8.3beta3 database  .... 
> Segmentation fault after ~10min
>     From the serverlog:
>     2007-11-27 11:03:27 CET [7133] LOG:  server process (PID 7337) was 
> terminated by signal 11: Segmentation fault
>     2007-11-27 11:03:27 CET [7235] CONTEXT:  COPY login_session, line 
> 9210986
>
> SECOND TRY:
>     Increased the loglevel to DEBUG1
>     pg_dump (v8.2.4)  --format=p    the PG 8.2.4 database into an 
> ASCII file (31 GB)  .... OK
>     psql-restore into a brandnew PG 8.3beta3 database  .... 
> Segmentation fault after ~2hours
>     From the serverlog:
> 2007-11-27 15:56:38 CET [15833] STATEMENT:  CREATE INDEX 
> login_session_promotion_id ON login_session USING btree (promotion_id);
> 2007-11-27 15:56:38 CET [15833] ERROR:  concurrent insert in progress
> 2007-11-27 15:56:38 CET [15833] STATEMENT:  CREATE INDEX 
> login_session_web_site_id ON login_session USING btree (web_site_id);
> 2007-11-27 15:56:50 CET [21670] DEBUG:  autovacuum: processing 
> database "gaia"
> 2007-11-27 15:57:58 CET [15726] LOG:  server process (PID 15833) was 
> terminated by signal 11: Segmentation fault
> 2007-11-27 15:57:58 CET [15726] LOG:  terminating any other active 
> server processes
>
> What could be the cause of this problem? Is it a bug or my fault?
> The postgres.crash.log is enclosed.
>
>

The general rule is: use pg_dump from the target version. So your first 
attempt was more correct.

Just curious: what happens if you turn autovacuum off before starting 
the restore?

cheers

andrew

Rudolf van der Leeden <vanderleeden@logicunited.com> writes:
> What could be the cause of this problem? Is it a bug or my fault?

It looks like a corrupted-data kind of problem.  Can you extract
a reproducible test case?
        regards, tom lane

> It looks like a corrupted-data kind of problem.  Can you extract
> a reproducible test case?

The problem was the hardware!!
On a second system (Mac Power G5) there was no failure, i.e. the  
error is not reproducible.
Thanks for your help.

Rudolf VanderLeeden