[HACKERS] Postgres 8.3 archive_command
Hi, I just installed v8.3beta3 and discovered that the way WAL archiving is handled has changed. From postgresql.conf: #archive_mode = off # allows archiving to be done (change requires restart) #archive_command = '' # command to use to archive a logfile segment In v8.2.4 we are currently switching archiving on/off on the fly by just inserting an archiving command. Now we have got a separate option for handling the on/off state. That's ok. But the note "change requires restart" is a serious change over v8.2. Background: We are using the archive_command for PITR backup every night. This can easily be done while the server is running. After the migration to v8.3 we'd have to (1) stop the server, switch on archiving, start the server, (2) run PITR backup, and (3) stop the server, switch off archiving, start the server. Questions: - Is the requirement "change of archive_mode requires restart" just temporary or is it going to stay in the final release? If the server restart is planned for final release (for whatever reason) then my next question is: - The workaround is a script that simply does a NOOP if archiving is effectively disabled while archive_mode=on all the time. How can one switch off the archiving log messages? Thanks and best regards, Rudolf VanderLeeden IT Consultant Logicunited GmbH Germany [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] 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=cthe 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=pthe 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 [EMAIL PROTECTED] postgres.crash.log Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PG 8.3beta3 Segmentation Fault during Database Restore
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
