3

I'm trying to simply install Drupal 7.8 on PostGreSQL 9.1, backup the DB, and then restore from it ... nothing else, just to test out backing up my sites, but the site will not come back up!

Here are my steps:

  1. install Drupal & get through configuration to the "you're done" screen
  2. dump the DB (pg_dump > file.sql)
  3. drop the DB (dropdb)
  4. create a new DB with the same info (createdb)
  5. restore the DB (psql < file.sql)

No steps in between (except when I've tried to avoid the error by putting the site into maintenance mode and/or clear the cache). No adding content, no nuthin'!

But when I access my site, I get the following error message:

[22-Nov-2011 17:07:44] PHP Notice:  unserialize() [<a href='function.unserialize'>function.unserialize</a>]: Error at offset 0 of 1009 bytes in /Applications/MAMP/htdocs/drupal-postgres/includes/cache.inc on line 405
[22-Nov-2011 17:07:44] PHP Notice:  unserialize() [<a href='function.unserialize'>function.unserialize</a>]: Error at offset 0 of 38585 bytes in /Applications/MAMP/htdocs/drupal-postgres/includes/cache.inc on line 405
[22-Nov-2011 17:07:44] PHP Warning:  Invalid argument supplied for foreach() in /Applications/MAMP/htdocs/drupal-postgres/includes/module.inc on line 185
[22-Nov-2011 17:07:44] PHP Warning:  array_keys() expects parameter 1 to be array, null given in /Applications/MAMP/htdocs/drupal-postgres/includes/module.inc on line 89
[22-Nov-2011 17:07:44] PHP Notice:  unserialize() [<a href='function.unserialize'>function.unserialize</a>]: Error at offset 0 of 38585 bytes in /Applications/MAMP/htdocs/drupal-postgres/includes/cache.inc on line 405
[22-Nov-2011 17:07:44] PHP Warning:  Invalid argument supplied for foreach() in /Applications/MAMP/htdocs/drupal-postgres/includes/module.inc on line 185
[22-Nov-2011 17:07:44] PHP Warning:  array_keys() expects parameter 1 to be array, null given in /Applications/MAMP/htdocs/drupal-postgres/includes/module.inc on line 89
[22-Nov-2011 17:07:44] PHP Fatal error:  Call to undefined function system_run_automated_cron() in /Applications/MAMP/htdocs/drupal-postgres/includes/common.inc on line 2573

Anyone have any thoughts? This CAN'T be this hard!

Thanks a million!

  • I've just tried to do the same thing using MySQL and it worked fine! Any thoughts, PostGres folks? – TizzyTool Nov 23 '11 at 1:40
2

After looking into this a bunch, I just decided to move the DB to MySQL. I hated to have to do it, but support for sql-dump in drush is limited to MySQL, and Backup and Migrate is as well. Kills me to have to run two DB servers (all my other applications use PostGres), but desperate times call for desperate measures.

I would hope some day that these modules would support PostGres. As Drupal supports both, so should the modules.

Some notes to others when using Backup and Migrate and Backup and Migrate Files

  • File ownership travels with the files, so I've had to "chown apache" files that get moved
  • It looks like the Temporary Directory setting is stored as a machine-specific folder, so be sure to update this on the destination machine
  • Clear the cache on the destination machine. I had a case where a tpl.php file wasn't being used until I did this.
1

Shot in the dark here, but I would take your backup a different way. You have two options:

One is to the Backup and Migrate module. I would set up the profile to ensure that tables are locked and drop into maintenance mode during backup to ensure that it is consistent. I would also exclude all of the content from the cache tables. While you are at it, set up a backup schedule.

The other is to use drush and it's sql-dump command. The author mentions that the proper options are used to ensure a backup, and you can also exclude table contents.

You could also try restoring your backup file and manually doing a TRUNCATE TABLE or DELETE FROM on all of the cache tables.

1

Check this up: http://drupal.org/node/926636

I have got almost the same errors while migrating to a different server as well as upgrading from postgres 8.4 to 9.0. Altering the bytea setting does the job so far!

1

You can also changed settings in the postgresql.conf so you don't have to altering the table each time you make a backup

bytea_output = 'escape' # hex, escape

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.