Posted by spydmobile on December 1, 2008 at 6:46pm
24 followers
| Project: | Backup and Migrate |
| Version: | 7.x-2.2 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Issue Summary
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.
Comments
#1
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.
#2
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
#3
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
#4
#5
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
#6
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.
#7
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.
#8
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:
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
#9
Hi Charles,
Results of testing:
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
#10
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:
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.
#11
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.
#12
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
#13
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#14
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...
#15
Last patch still wrond against 6-1.2 if someone already have a working copy please make a new patch
#16
subscribing
#17
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!
#18
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
#19
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.
#20
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.
#21
Nope, it's still a feature request.
#22
Which means that there is no PostgreSQL support.
#23
agree with jleinenbach, supporting the basic drupal requirements is not a 'feature'. This module literally does not work at all.
#24
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
#25
Charles,
I get a "Could not complete the backup" error message when I try to use Advanced. Any ideas?
#26
exactly the same message as possum4all, hope you have any ideas ...
#27
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.
#28
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?
:(
#29
any progress on this feature?
#30
Wondering the same...
#31
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,
#32
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
#33
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.
#34
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,
#35
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
#36
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.
#37
Don't forget to check your file permissions?
#38
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,
#39
subscribe
#40
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.
#41
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,
#42
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.
#43
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
#44
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,
#45
@vividgates
Thank you that fixed it!!!!
#46
=)
#47
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.
#48
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 :)
#49
Don't change the version number, but start a new ticket, since this thread has patches for the 6.x version.
#50
[34] seems to be working with latest stable (7.x-2.2) fine. Please try to commit it.
#51
Hi all,
I have created a Git repo on GitHub that includes the PostgreSQL patch from Jeffrey Esquivel S. so one don't have to manually apply the patch for this module.
It uses Backup and Migrate source code from tag 7.x-2.2 (http://drupalcode.org/project/backup_migrate.git/tree/49da07ebe6d5d3bd11...)
By clicking on the "Downloads" link on the top left you will get a .zip file (.tar.gz does not seem to work) that can be directly installed via Drupal' "Install a new module" page.
https://github.com/tkrotoff/drupal_backup_migrate
Please update the module homepage to say that it does not work with PostgreSQL. I've lost quite some time figuring out what was going on with my setup just because I didn't have this information.
#52
I have moved to MySQL instead of PostgreSQL. Even if Drupal is advertised as working with PostgreSQL most modules don't (Backup and Migrate and Organic groups in my case).
#53
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.
#54
Couldn't edit back from closed (fixed), selected by mistake...
#55
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.
#56
Well we're at it, let's add SQLite support too.
#57