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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
