I have to agree with other comments, for a module to be prime time, it should support both official databases. I notice that someone has offered to help you with this issue, I sincerely hope you take the offer, I am excited to try your module on my pg-drupal systems. Lastly, since I had to install your module, find that it fails to work correctly, come and submit a bug only to find that it never did support PGSQL, I would suggest that you add that fact to the description of the module in bold. Pehaps "This module does not support PostgreSQL (yet)". Thanks for contributing and keep up the good work, I look forward to your module when it supports PGSQL.

For the record, this is the error returned when this module is installed and run on PGSQL



    * warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near "table" LINE 1: show table status ^ in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\cms\includes\database.pgsql.inc on line 138.
    * user warning: query: show table status in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\cms\sites\all\modules\backup_migrate\backup_migrate.module on line 669.
    * warning: Invalid argument supplied for foreach() in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\cms\includes\form.inc on line 1417.
    * warning: Invalid argument supplied for foreach() in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\cms\includes\form.inc on line 1417.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Charles Oertel’s picture

I am working on adding postgres and multiple databases to this module.

Some functionality to do this is already in db_maintenance module, and I am creating a dependency between the two modules. Give me a few days and we will see where we get to.

Charles Oertel’s picture

This module now seems to work with postgres and mysql (I didn't test mysql since I am using postgres). It also works if you have one or more than one database defined, and should even work if some of the databases are postgres and others are mysql.

Unfortunately, the magic for this intelligence comes from the db_maintenance module, and I am not going to cut-n-paste. So I have added that module as a dependency to this one. You need to use the patched version of that module, here:
http://drupal.org/node/306872#comment-1204027

ronan’s picture

Category: bug » feature
Priority: Critical » Normal
Status: Active » Needs work

Thanks for the hard work. I'm not going to commit a patch that introduces a module dependency to a patched module as it would raise the barrier of entry a little high, but this could be very useful for posgres users who want this functionality.

I'd love to hear PGSQL users' take on whether this works and if it's a good solution, as there maybe a way forward using some sort of conditional dependency.

Thanks again.
r

ronan’s picture

Status: Needs work » Needs review
aaron1234nz’s picture

Status: Needs review » Needs work

Hi Charles/Ronan.

I've just given the patch a test. It did not quite apply cleanly against the latest dev, but it was close. I've also applied the patch to db_maintainance, and that went smoothly.

I've just attempted to do a backup of my Postgres database. However when I do I get a 0 byte file back. So something is not right. I had compression turned off and it made no difference if I downloaded the file or have it save to my files directory.

I'm running postgres 8.3 on windows

Charles Oertel’s picture

Hi Aaron

I'm getting the empty backup now too - even though the module worked perfectly on Friday. It may have something to do with the latest dev, because I applied it to my version before using the module this morning. Will let you know.

In one manual test, I got a timeout on a very large database, so that might be one of the issues.

Ronan, I understand the dependency issue and suspected I might be chastised for doing such a thing. One workaround would be to copy the functions across into this module, but we know that refactoring is the proper solution in the long term. Or maybe we can pool resources and have this module supercede db_maintenance? Especially since this one has more functionality and now (theoretically) supports all the databases.

I'll do a new patch when I find the problem.

ronan’s picture

I made some changes to the latest dev on friday, so that might be the issue. I am trying to keep the 1.x branch stable, but I applied a patch that helps fix some fairly serious issues with temp files not being deleted. That'll hopefully be last big change to the 1.x branch so that won't get in your way.

As to the dependency, I certainly didn't mean to chastise. I'm very happy that you're taking the time and the initiative to work on this issue. I don't mind the dependency either as long as it doesn't complicate life for MySQL users. A conditional warning that checks for the db_maintenance module if the current db is postgres should work. That way, pgsql users would get info on how to enable the module for their situation but MySQL users would be none the wiser, and would not have to install an unnecessary module just to satisfy a dependency.

Once you get something working and stable and vetted by the pgsql community (I don't use postgres it much at all, and am extremely unfamiliar with it's dump formats, so I won't be much use) then I'll either commit it to the 1.x branch with the dependency warning, or refactor it for inclusion in the 2.x branch.

Thanks again for your hard work.

Charles Oertel’s picture

Fixed the problem where the database is created empty. Two problems, one a bug, the other the fact that pg_dump does not accept passwords in the parameter list. In situations where the db connection requires a password, this is what now happens:

  1. the call to db_maintenance to get the postgres options, will result in a file called .pgpass being created, populated with the logon credentials for the database as set in settings.php, and place the file in the parent of the drupal directory with appropriate permissions.
  2. the call to pg_dump sets the PGPASSWORDFILE environment variable to point to that file so that pg_dump can use it.

This patch also includes the latest of Ronan's releases, so temp files are being deleted as intended.

Remember to satisfy the dependency of this module with db_maintenance, patched to http://drupal.org/node/306872#comment-1210575

aaron1234nz’s picture

Hi Charles,

Results of testing:

  • I've applied your new patches against the latest stable release but the patch did not apply cleanly (the backup_migrate_cron part failed ... there seems to be an if statement in the place of a foreach missing in the surrounding cod).
  • The settings for choosing the paths to pgdump etc. are hard coded in. As I use Windows I had to modify the code to get it to do anything
  • I don't have a password on the database I was testing with, but setting the environment variable does not float well on Windows (you can't execute two commands separated with a semicolon for a start) See http://www.mail-archive.com/pgsql-patches@postgresql.org/msg08305.html
    • However the files generated were good and contained (at first glace at least) the right stuff.

      Thanks for the work your putting into this!

      Aaron

Charles Oertel’s picture

Aaron

My apologies. Firstly for not monitoring this thread over the last two weeks, and secondly for having completely forgotten the issues with running on Windows. I switched to linux 6 years ago and can no longer even imagine the difficulty of getting anything to work there. I propose two fixes to your problems:

  • Put the .passwd file path into the pgdump command line with a parameter, instead of passing it as a session variable, and
  • Not specifying any paths to executables, those executables must be on the system path

Our system is going into testing soon, and only then will I be likely to work on this code again. If I do I will submit a new patch, or, if the module allows, integrate my changes into the new version.

aaron1234nz’s picture

Thanks Charles,

I've got a couple of pressing projects on the go at the moment, but once I'm through those I'll get a patch together. I should switch to linux but haven't had the time/inclination to get used to a new environment yet.

vinzentt’s picture

Hi,

first of all thanks for this patch, but i had to modify several things to get it work in backup and migrate and in db_maintenance :

- environment variable is neither DBPASSWORDFILE nor PGPASSWORDFILE but PGPASSFILE according to libpq documentation: http://www.postgresql.org/docs/8.1/static/libpq-pgpass.html
- the .pgpass should be in the user home directory (apache user, so normally /var/www) with 600 for permissions

i don't post a patch 'cause i modified more than that and it concerns both modules.

but if needed i can clean my code and post it.

--
Vincent

spydmobile’s picture

good call vinzentt, but this is a better URL becuase 8.1 has fundamental differences in syntax than recent versions, so this is a better URL so as to not introduce accidental bugs becuase of old syntax...

http://www.postgresql.org/docs/8.3/static/libpq-pgpass.html
spydmobile’s picture

Sorry I am not a Patcher.... I have run the latest release version and this is the result upon trying to config the module:

    * warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near "table" LINE 1: show table status ^ in /var/www/sparcs/includes/database.pgsql.inc on line 139.
    * user warning: query: _backup_migrate_get_table_names show table status in /var/www/sparcs/sites/all/modules/backup_migrate/backup_migrate.module on line 682.
    * warning: Invalid argument supplied for foreach() in /var/www/sparcs/includes/form.inc on line 1420.
    * warning: Invalid argument supplied for foreach() in /var/www/sparcs/includes/form.inc on line 1420.

Dont know if this helps or not..... If you folks release something I can use (a dev or a release) I would be happy to feed back...

andypost’s picture

Last patch still wrond against 6-1.2 if someone already have a working copy please make a new patch

xlyz’s picture

subscribing

sailtexas’s picture

Hi and thanks for your work,

I'm running a fresh install of Drupal 6.14 on pgsql and I'm also running poormanscron.

My error msg:
* warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near "table" at character 6 in /var/www/vhosts/lordnelsonyachts.org/httpdocs/includes/database.pgsql.inc on line 139.
* user warning: query: show table status in /var/www/vhosts/lordnelsonyachts.org/httpdocs/sites/all/modules/backup_migrate/backup_migrate.module on line 682.
* warning: Invalid argument supplied for foreach() in /var/www/vhosts/lordnelsonyachts.org/httpdocs/includes/form.inc on line 1428.
* warning: Invalid argument supplied for foreach() in /var/www/vhosts/lordnelsonyachts.org/httpdocs/includes/form.inc on line 1428.

I'll be happy to assist in any way possible!

danielb’s picture

downloaded this module today



    * warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near "table" LINE 1: show table status ^ in /srv/www/htdocs/deepend/html/secure/includes/database.pgsql.inc on line 139.
    * user warning: query: show table status in /srv/www/htdocs/deepend/html/secure/sites/all/modules/backup_migrate/backup_migrate.module on line 682.
    * warning: Invalid argument supplied for foreach() in /srv/www/htdocs/deepend/html/secure/includes/form.inc on line 1428.
    * warning: Invalid argument supplied for foreach() in /srv/www/htdocs/deepend/html/secure/includes/form.inc on line 1428.

6.x-1.2

danielb’s picture

I downloaded the 6.x-2.x release and it just white screens when you try to visit the admin page for the module. Sorry no access to error log.

jleinenbach’s picture

Category: feature » bug

If it doesn't work with PostgreSQL and the patch is ignored, then there is either no PostGreSQL-support at all and this is a feature request or the module buggy and there's no information that this is a MySQL-only module.

ronan’s picture

Version: 6.x-1.2 » 6.x-2.x-dev
Category: bug » feature

Nope, it's still a feature request.

jleinenbach’s picture

Which means that there is no PostgreSQL support.

danielb’s picture

agree with jleinenbach, supporting the basic drupal requirements is not a 'feature'. This module literally does not work at all.

Charles Oertel’s picture

Title: Does not work on pgsql » postgres version
Status: Needs work » Needs review
FileSize
71.98 KB

Hi all

Attached is a version of backup and migrate 6.x-2.x-dev merged with my code to support pgsql. I use it on LAMP to do manual and scheduled backups of a site with two psql databases. The quick-backup part does not work because I have not needed it. Advanced backup works, as well as scheduled backups. Restores and downloads work well - I regularly download a database from one website and upload it to the next.

I did not create a patch - this is the full package. Ronan, it would be great if you could merge this with your base. I have removed all dependency on the db_maintenance module, so this is now completely standalone.

kind regards
Charles

possum4all’s picture

Charles,
I get a "Could not complete the backup" error message when I try to use Advanced. Any ideas?

sense-design’s picture

exactly the same message as possum4all, hope you have any ideas ...

suzanne.aldrich’s picture

This looks like a cool module, but unfortunately I installed it without reading the README.txt that says it doesn't work with postgres. It would be a good idea to stick that on the front page of the project, because I always read that carefully before trying modules to ensure that they are compatible with my db, and many db-intensive ones make note of their compatibility.

Looks like a cool module; keep up the good work! I'll test out and help more when this postgres stuff is hammered out a little more.

xavipal’s picture

I saw that, when the backup and migrate module, build the call to pg_dump command the file path is not correct. Maybe this is the reason because we see the "Could not complete the backup". I copied and pasted the call directly into the msdos console and I notice
that the generated command return an "access denied" because the path is something like folder folder temp_folder/name_file.

It seems that the module delete the "\" when creating the path.

this is the error on reports:

exec(): Unable to fork [PGPASSFILE=E:\xxx\xxx\Drupal\sites\default\Temp_drupal/backup_migrate_4c4ea68c90824. pg_dump -c --no-owner --host=127.0.0.1 --port=5432 --username=xxx drupal > E: xxx xxx Drupal sites default Temp_drupal/backup_migrate_4c4ea68c87683.backup-2010-07-27T11-27-40.pgsql] in E:\xxx\xxx\Drupal\sites\all\modules\backup_migrate\includes\destinations.db.pgsql.inc on line 114.

Can someone see if this is the problem, and how to fix it?

Thanks a lot!!

EDIT. Now I just have a blank page using the quick backup or the "Could not complete the backup." using the Advanced one ...
Why this module doesn't works?
:(

threading_signals’s picture

any progress on this feature?

Gallaecio’s picture

Wondering the same...

jeff.esquivel’s picture

Hi,

The included patch adds support for PostgreSQL to the latest release (7.x-2.0). I only tested the export functionality (both basic and advanced) and it seemed to work fine, but there are still much improvements that can be made (I already have several in mind).

Please think of this code as alpha quality (is my first patch for a Drupal module), so don't count solely on it for your production site's database backup.

Right now, the database dump is made with pg_dump, so you will need to have it installed for this to work, I'll like to hear if anyone knows a better way to do this that doesn't require any external tool.

The company I work for is interested in PostgreSQL support, so I may be able to keep working on this patch until it becomes production-quality code. I would really appreciate any feedback I can get from users as well as developers.

Regards,

ronan’s picture

Aweseome! Thanks for your help on this. I hope others can take the time to test this so we can get it rolled into the module.

Ronan

suzanne.aldrich’s picture

Since Drupal 5 is no longer supported, it would be good if this worked in the 5 version since lots of people will want to escape from their ancient installations.

jeff.esquivel’s picture

Hi,

Just updated the patch to apply cleanly on the latest version (7.x-2.1) also fixed a couple of bugs and tested several more cases.

Bugs fixed:

* A warning about an uninitialized variable when no table was selected on the "Exclude the following tables altogether" list.
* The backup file would be empty unless a table was selected on the "Exclude the data from the following tables" list.

Regards,

ronan’s picture

Awesome, thanks for your hard work, Jeff. Sounds like you're getting close on this.

In terms of future support and maintenance. I'm afraid I will be unable to help much with any future Postgres issues since I don't use it day-to-day so before this gets rolled in, I'd need somebody on-board to help maintain this aspect of the code. Would you be willing to help out with that? We may even want to have you create your own project for this code so you can have your own issue queue, and your own release schedule (you could release the 'alpha' ready code as 'alpha' and let more users help test it for you). Is that something you might be willing to do? Same question to goes out to any of the other Postgres coders who have helped out on this issue.

R

Anonymous’s picture

I'm not having any luck with the patch. Tested on the 7.x-2.1 build. Patching went okay but I got 500 errors any time I tried to access the module.

threading_signals’s picture

Don't forget to check your file permissions?

jeff.esquivel’s picture

Hi,

Could you please fill me in with some information about your environment? Anything you think could be related to the problem, specially anything from your logs which seems to be related to it.

Regards,

ogi’s picture

subscribe

Anonymous’s picture

Sorry for the delays as I've been tremendously busy with another project.

I'm running on a pretty typical setup:
Debian Squeeze
PHP 5.35
PostgreSQL 9
Apache 2.2
Drupal 7.0

I don't have anything going on whatsoever that a normal, dedicated server shouldn't have and my file permissions are set up to proper standards.

jeff.esquivel’s picture

Hi NANEPUSS,

Sorry for the delayed answer, I guess we all are really busy, he he.

Well, I installed a VM with Debian Squeeze to test in the same environment as you, and then I realized you said you were using PostgreSQL 9 on it, do you think the problem could be related to this?:

http://petereisentraut.blogspot.com/2011/02/squeeze-postgresql-broken.html

And anyway, if it is not, could you please tell me where you installed your PostgreSQL 9 from?

In the mean time, I'll still try it on PostgreSQL 8.4 to see if the problem is related to something else on that platform.

Regards,

Anonymous’s picture

Thanks for the reply. My memory is a tad fuzzy on where I installed it from but I'm fairly certain it was the repo straight from the Postgre website. I'm working on that project tomorrow so I'll screw with a bit and get back to you. To be perfectly honest though, I'll probably roll back to 8.4 if it means I cannot use this module. We only used 9 because the majority of people said it should be relatively safe to use for new projects.

threading_signals’s picture

bytea_output = 'escape' in postgresql.conf and perhaps the other lines are needed for postgresql 9:

standard_conforming_strings = on
escape_string_warning = off

Regards,

Paul

jeff.esquivel’s picture

Hi NANERPUSS,

I just tested it with a basic Drupal 7 installation (the only module installed was backup and migrate) running on Apache2, PHP5 and PostgreSQL 8.4 (all downloaded from the standard Squeeze repositories) and everything works as expected.

I will try to find the repository you talk about for PostgreSQL 9 and test it with that.

Regards,

Anonymous’s picture

@vividgates

Thank you that fixed it!!!!

threading_signals’s picture

=)

andrew_k’s picture

It seems to me that the focus of this issue has shifted from 6.x to 7.x. I use backup migrate on all my projects but have just inherited a drupal 6 site that uses postgres so I would love postgres support in 6.x.

Has anyone had any luck with the code in #24? I could backup a database using the advanced backup but when I tried to restore it failed without much of an explanation. I am going to have a bit of a play with the code and see if I can make any progress. I will also try to merge the code back into 6.x-2.x-dev and create a patch if I get anywhere.

spatialguru’s picture

Version: 6.x-2.x-dev » 5.x-1.x-dev

Similar to andrew_k - I've inherited an older version of drupal (5.x) and it uses postgres. Anyone got this module to work?

ed: Also not working for me on 6.x. Ack.. my host runs PG 8.1 - I'm sure that's not helping :)

threading_signals’s picture

Version: 5.x-1.x-dev » 6.x-2.x-dev

Don't change the version number, but start a new ticket, since this thread has patches for the 6.x version.

kmajzlik’s picture

Version: 6.x-2.x-dev » 7.x-2.2
Status: Needs review » Patch (to be ported)

[34] seems to be working with latest stable (7.x-2.2) fine. Please try to commit it.

Anonymous’s picture

Anonymous’s picture

Title: Add support for PostgreSQL databases » postgres version
tamahome14’s picture

Status: Patch (to be ported) » Closed (fixed)

Used patch from #34 and for drupal 7.12, postgres 8.4, apache 2.2, debian squeeze 2.6.32-5-686, it's working for "backup now".
Will try to apply the same patch in the prodution 6.x drupal and test export/ import feature to see if it can be used to upgrade drupal sites from 6.25 to 7.12.

tamahome14’s picture

Status: Closed (fixed) » Patch (to be ported)

Couldn't edit back from closed (fixed), selected by mistake...

tamahome14’s picture

Trying to import a pgdump file backup from a drupal 6.x was not sucessful. The module only executed 2 commands. I will try couple more things before moving on.

Gaelan’s picture

Title: postgres version » Multiple Databases

Well we're at it, let's add SQLite support too.

ronan’s picture

Title: Multiple Databases » Add support for PostgreSQL databases
boabjohn’s picture

Title: postgres version » Add support for PostgreSQL databases

Very sorry to be lost in the patches and versions queue here...but can I get a quick clue as to the current state of affairs?
We are running the 3.x dev branch and under Settings>Sources there is no hint that PostGreSQL is an option.
What should we do?
Thanks in advance,
JB

boabjohn’s picture

Hi guys...is this issue dead or just a zombie?
I'm new to the world of PostgreSQL. Looks like a great database by gosh it's a drama getting some of the key modules (like the always-adored backup_migrate) to play nicely.
I'd be keen to hear how some of the more veteran PostgreSQLians manage their backups in the absence of BAM.
Kind regards,
JB

boabjohn’s picture

And as far as I can tell, the patch at #34 is now outdated. Tried running the patch and it fails:

e# patch -p0 < backup_migrate-postgresql-341277-34.patch
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -urPp backup_migrate/backup_migrate.module backup_migrate.new/backup_migrate.module
|--- backup_migrate/backup_migrate.module       2011-01-24 23:35:36.000000000 -0600
|+++ backup_migrate.new/backup_migrate.module   2011-01-30 19:58:20.269030356 -0600
--------------------------
File to patch: backup_migrate.module
patching file backup_migrate.module
Hunk #1 succeeded at 1178 (offset 558 lines).
can't find file to patch at input line 16
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -urPp backup_migrate/includes/db.inc backup_migrate.new/includes/db.inc
|--- backup_migrate/includes/db.inc     2009-07-05 22:26:53.000000000 -0600
|+++ backup_migrate.new/includes/db.inc 2011-01-30 20:00:13.286100925 -0600
--------------------------
File to patch: includes/db.inc
includes/db.inc: No such file or directory
Skip this patch? [y] y
Skipping patch.
1 out of 1 hunk ignored
patching file backup_migrate/includes/destinations.db.pgsql.inc
can't find file to patch at input line 318
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -urPp backup_migrate/includes/destinations.inc backup_migrate.new/includes/destinations.inc
|--- backup_migrate/includes/destinations.inc   2011-01-24 23:35:36.000000000 -0600
|+++ backup_migrate.new/includes/destinations.inc       2011-01-30 20:12:11.909058963 -0600
--------------------------
File to patch: backup_migrate/includes/destinations.inc
backup_migrate/includes/destinations.inc: No such file or directory
Skip this patch? [y] y
Skipping patch.
2 out of 2 hunks ignored
suzanne.aldrich’s picture

I think this is a zombie issue, but I'm not sure if it's completely dead or just moved along.

In any case, I'm in the process of migrating off postgres to mysql for the reason of lack of rigorous support, at least in Drupal 6, for postgres in many contrib modules. It's a great database but it's been difficult to make run with any but the most popular modules, and even then I've had to muddle through manually patching things together.

For backing up and restoring your database with PostgreSQL dumps, refer to the community documentation:
https://drupal.org/upgrade/backing-your-site-command-line

If you have Drush installed you can run archive-dump and get a format which can be restored using archive-restore:
https://github.com/drush-ops/drush

junedkazi’s picture

Version: 7.x-2.2 » 7.x-2.x-dev
Status: Patch (to be ported) » Needs work
slashack’s picture

Patch for 7.x-2.8

I've just took patch from #34 and manually implemented it on current 7.x version.

Hope it helps.

sfcamil’s picture

Fatal error: require_once(): Failed opening required '............backup_migrate/includes/destinations.db.pgsql.inc' (include_path=............... sites\all\modules\utils\backup_migrate\includes\filters.backup_restore.inc on line 162

because the patch create a new directory backup_migrate.new and put the file destinations.db.pgsql.inc there.

Moved the file on the right place and module install ok. But click on configure go to admin/config/system ...

sfcamil’s picture

Ok my fault. Just want to install the module with the patch already applied. Uninstalled the module and installed again .. after that applied the patch and all ok. I see default database in 'Backup from' but "Could not complete the backup" . continue to search. Backup directory already set. ....

boabjohn’s picture

Looks very promising: thanks for kicking the can along @slashack!
I'm not getting the patch to apply though...

I removed the directory, re-downloaded the current dev, and ran drush updb.

Then loaded the patch and applied it. Failures:

patching file backup_migrate.module
Hunk #1 FAILED at 671.
1 out of 1 hunk FAILED -- saving rejects to file backup_migrate.module.rej
patching file includes/destinations.db.pgsql.inc
patching file includes/destinations.inc
Hunk #1 FAILED at 21.
Hunk #2 FAILED at 68.
2 out of 2 hunks FAILED 

Any clues?

slashack’s picture

New patch for 7.x-3.0 branch.

It works for me... Manually ported the old patch to the new architecture in the 3.0 branch.

AgentJay’s picture

I've patched the Latest stable version of Backup and Migrate (7.x-3.0) with the patch from #67.

I get the following 2 errors:
Notice: Undefined index: name in backup_migrate_source_db_pgsql->_get_views() (line 225 of /srv/www/testdelta/sites/all/modules/backup_migrate/includes/sources.db.pgsql.inc).
Notice: Undefined index: name in backup_migrate_source_db_pgsql->_get_view_names() (line 170 of /srv/www/testdelta/sites/all/modules/backup_migrate/includes/sources.db.pgsql.inc).

Looking into the patches, it appears the patches assume you have all of the previous patches? The latest patch doesn't include the modifications in destinations.db.inc or the addition of destinations.db.pgsql.inc.

Can you maybe upload a copy of your entire module that you are using slashack?

Thanks.

AgentJay’s picture

My errors pointed to the fact that the queries that show the eventual tables/views:

SELECT * FROM information_schema.tables WHERE table_schema = 'public' ORDER by table_name ASC
SELECT * FROM information_schema.views WHERE table_schema = 'public' ORDER by table_name ASC

gets the names of the tables in a column called 'table_name' and not just 'name', although that much is indicated in your sort order, so I'm not sure if I'm on the right track...

I updated the occurrences of $view['name'] to $view['table_name'] and $table['name'] to $table['table_name']

The errors are gone. Now under 'DEFAULT DATABASE BACKUP OPTIONS' where you can 'omit specific tables' I get a list of views in my drupal database rather than a list of tables. Something is mixed up somewhere.

If I try to backup with or without the views I get a 'Could not complete the backup.' error.

TurkishCoffee’s picture

I'm a little confused what's going on here. Is it only PostgreSQL 9 that has issues? Do any versions work and if so which versions?

alienseer23’s picture

Hey folks, I am wondering how this plays out on 7.x-3. Reading through the comments it appears as if I may or may not need to apply all of the patches in order? Is this true?

Does this work? I would love to have this function for this module.

Applying slashack's patch, and only that patch, from comment #67 works just fine for me. I am currently backing up a postgresql v9.1 database (from another application, even) over sftp to a remote location.

Drupal is now a backup monster. Thank you for you awesome work.

slashack’s picture

Patch from #67 still works on 7.x-3.1

DamienMcKenna’s picture

This appears to be working, but it hits an out-of-memory error:

$ drush -v bb 
Executing: PGPASSFILE=/tmp/drush_ndVNdu psql -q --dbname=drupal_d7 --host=localhost --port=5432 --username=web  --no-align --field-separator='	' --pset tuples_only=on --file /tmp/drush_vymJ5n
Executing: PGPASSFILE=/tmp/drush_0cDKwG psql -q --dbname=drupal_d7 --host=localhost --port=5432 --username=web  --no-align --field-separator='	' --pset tuples_only=on --file /tmp/drush_LGIgnA
Starting backup...                                                                                                [notice]
PHP Fatal error:  Allowed memory size of 536870912 bytes exhausted (tried to allocate 450101211 bytes) in /var/www/html/sites/all/modules/contrib/backup_migrate/includes/sources.db.pgsql.inc on line 113
Drush command terminated abnormally due to an unrecoverable error.                                             [error]
Error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 450101211 bytes) in
/var/www/html/sites/all/modules/contrib/backup_migrate/includes/sources.db.pgsql.inc, line 113
pg_dump: [archiver] could not write to output file: Broken pipe

I don't have access to change php.ini on this server,

Also, the patch needs a little fixing for the Drupal coding standards - tabs, newlines before 'else' statements, etc.

joel_osc’s picture

Seeing same result - out of memory error even with memory limit set very large:

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1002127240 bytes) in /var/www/html/mysite/sites/all/modules/contrib/backup_migrate/includes/sources.db.pgsql.inc on line 113

Made a small change that seems to fix this, just added 2>&1 at the end of line 108 so that STDERR is included in the popen so fgets sees the EOF.

108           $dump_cmd = escapeshellcmd("PGPASSWORD=" . $settings->source->dest_url['pass']  . " pg_dump --clean --no-owner --host=" . $settings->source->dest_url['host'] . " -    -username=" . $settings->source->dest_url['user'] . $exclude_tables . " " . $settings->source->dest_url['path'] . " 2>&1");
109            $handle = popen($dump_cmd, "r");
110            $output = "";
111            $lines = 0;
112            while ($output_line = fgets($handle)) {
113              $output .= $output_line;
114              $lines++;
115            }

Can someone else give this a try?

DamienMcKenna’s picture

I'd suggest checking out the PostgreSQL support for Drush's sql-dump command to get some ideas on how this could be handled better.

couturier’s picture

Status: Needs work » Closed (won't fix)

This issue has been filed against the 2.x branch. @DamienMcKenna has proposed that the 7.x-2.x branch be deprecated once the upgrade path to 7.x-3.x is verified. See this issue: Verify 7.x-2.x -to- 7.x-3.x upgrade path, mark 7.x-2.x as unsupported

In order to reduce the maintenance burden the 7.x-2.x branch should be deprecated. In order to do this the upgrade path to 7.x-3.x has to be verified and any issues fixed.

If this is a feature that needs to be included in the D8 version of Backup and Migrate, please re-open under an updated version or contribute to the conversation at the D8 Backup and Migrate Roadmap.

couturier’s picture

Version: 7.x-2.x-dev » 7.x-3.2
Status: Closed (won't fix) » Active

@DamienMcKenna so is this a feature request that should be bumped to 7.x-3.2 or should we file it in the 8.x branch?

DamienMcKenna’s picture

Version: 7.x-3.2 » 7.x-3.x-dev
Status: Active » Needs work

Lets work on fixing this as-is for D7.

DamienMcKenna’s picture

Issue tags: +PostgreSQL
DamienMcKenna’s picture

Title: Add support for PostgreSQL databases » Add support for PostgreSQL (D7)
DamienMcKenna’s picture

Status: Needs work » Needs review

The last submitted patch, 8: backup_migrate-6.x-1.2.module.patch, failed testing. View results

The last submitted patch, 2: backup_migrate-6.x-1.0.info_.patch, failed testing. View results

The last submitted patch, 2: backup_migrate-6.x-1.0.module.patch, failed testing. View results

The last submitted patch, 34: backup_migrate-postgresql-341277-34.patch, failed testing. View results

The last submitted patch, 8: backup_migrate-6.x-1.2.info_.patch, failed testing. View results

The last submitted patch, 31: backup_migrate-postgresql-341277-31.patch, failed testing. View results

The last submitted patch, 63: backup_migrate-postgresql.patch, failed testing. View results

cmseasy’s picture

Patch from #67 still works on 7.x-3.5, I did not test in dev.
No issues found.

joel_osc’s picture

Same for me, patch works great! Thank-you.

Status: Needs review » Needs work

The last submitted patch, 67: backup_migrate-7.x-3.0-postgresql.patch, failed testing. View results

DamienMcKenna’s picture

Status: Needs work » Needs review
DamienMcKenna’s picture

DamienMcKenna’s picture

Title: Add support for PostgreSQL (D7) » New backup source: PostgreSQL (D7)
DamienMcKenna’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

This needs a reroll.

mrinalini9’s picture

Assigned: Unassigned » mrinalini9
mrinalini9’s picture

Assigned: mrinalini9 » Unassigned
Status: Needs work » Needs review
FileSize
13.63 KB

Rerolled patch #93, please review.

Status: Needs review » Needs work

The last submitted patch, 97: backup_migrate-n341277-97.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

sanjayk’s picture

Assigned: Unassigned » sanjayk
sanjayk’s picture

Assigned: sanjayk » Unassigned

Little bit busy in next couple of days. Later will plan to work on it.