Thread: 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
Attachment
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