By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,264 Members | 1,228 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,264 IT Pros & Developers. It's quick & easy.

Postgres 7.x and Legato backup

P: 1
We are running a PHP web-based frontend with a Postgres 7.2 backend on a Windows 2000 Server box with automated backups of the server being handled by Legato. We are experiencing several problems that point in the general direction of the backup process but we have nothing concrete.

The Legato system runs incremental backups Monday through Saturday with a full server backup on Sunday. The problems we are seeing are mainly database performance related during the week (slow query response, slow writes). The big problems comes on Sunday either during or immediately after the full backup. The postmaster service will stop and not restart. User are getting 3008 DB connection errors of course because the postmaster service is no longer running.

We are also seeing some file locking and other oddities in the postmaster log (log extract below).

Has anyone experienced similar issues? As I mentioned, we suspect the Legato backup but we have no smoking gun at this point.

postmaster log
----------------------
WARNING: there is already a transaction in progress
PANIC: could not open file "/var/lib/pgsql/data/pg_xlog/000000000000006B" (log file 0, segment 107): Device or resource busy
STATEMENT: CREATE TEMPORARY TABLE tmp_appuser ("id_user" int4)
LOG: server process (PID 26728) was terminated by signal 6
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.
LOG: all server processes terminated; reinitializing
LOG: all server processes terminated; reinitializing
Usage:
postgres -boot [OPTION]... DBNAME
-c NAME=VALUE set run-time parameter
-d 1-5 debug level
-D datadir data directory
-F turn off fsync
-o file send debug output to file
-x num internal use
LOG: database system was interrupted at 2007-07-07 08:45:37 BST
PANIC: could not open file "/var/lib/pgsql/data/pg_xlog/000000000000006B" (log file 0, segment 107): Device or resource busy
LOG: startup process (PID 30124) was terminated by signal 6
LOG: aborting startup due to startup process failure
WARNING: dup(0) failed after 3195 successes: Bad file descriptor
LOG: database system was interrupted at 2007-07-07 08:45:37 BST
LOG: checkpoint record is at 0/6BAF25F0
LOG: redo record is at 0/6BAF25F0; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 1089088; next OID: 775710
LOG: database system was not properly shut down; automatic recovery in progress
LOG: record with zero length at 0/6BAF2630
LOG: redo is not required
LOG: database system is ready
WARNING: there is already a transaction in progress
WARNING: there is already a transaction in progress
WARNING: there is already a transaction in progress
Jul 9 '07 #1
Share this Question
Share on Google+
1 Reply


Expert 100+
P: 534
I am not familiar with the Legato (EMC Legato?) backup, but if this system is designed for file backup (vs. hot database backup) you indeed may have a problem.
Aside of the errors you reported a file-type backup made off the running database does not guarantee to produce a usable snapshot of the database.
I would consider not using Legato for PGDATA directory, pg_dump is safe and can be used on a running database.
The drawback of course is having to always generate a full backup, but for many people this is not a huge problem.
Jul 9 '07 #2

Post your reply

Sign in to post your reply or Sign up for a free account.