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.
Comment | File | Size | Author |
---|---|---|---|
#97 | backup_migrate-n341277-97.patch | 13.63 KB | mrinalini9 |
#93 | backup_migrate-n341277-93.patch | 13.78 KB | DamienMcKenna |
#67 | backup_migrate-7.x-3.0-postgresql.patch | 14.04 KB | slashack |
#63 | backup_migrate-postgresql.patch | 12.55 KB | slashack |
#34 | backup_migrate-postgresql-341277-34.patch | 12.96 KB | jeff.esquivel |
Comments
Comment #1
Charles Oertel CreditAttribution: Charles Oertel commentedI 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.
Comment #2
Charles Oertel CreditAttribution: Charles Oertel commentedThis 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
Comment #3
ronan CreditAttribution: ronan commentedThanks 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
Comment #4
ronan CreditAttribution: ronan commentedComment #5
aaron1234nz CreditAttribution: aaron1234nz commentedHi 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
Comment #6
Charles Oertel CreditAttribution: Charles Oertel commentedHi 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.
Comment #7
ronan CreditAttribution: ronan commentedI 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.
Comment #8
Charles Oertel CreditAttribution: Charles Oertel commentedFixed 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
Comment #9
aaron1234nz CreditAttribution: aaron1234nz commentedHi 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
Comment #10
Charles Oertel CreditAttribution: Charles Oertel commentedAaron
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.
Comment #11
aaron1234nz CreditAttribution: aaron1234nz commentedThanks 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.
Comment #12
vinzentt CreditAttribution: vinzentt commentedHi,
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
Comment #13
spydmobile CreditAttribution: spydmobile commentedgood 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...
Comment #14
spydmobile CreditAttribution: spydmobile commentedSorry I am not a Patcher.... I have run the latest release version and this is the result upon trying to config the module:
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...
Comment #15
andypostLast patch still wrond against 6-1.2 if someone already have a working copy please make a new patch
Comment #16
xlyz CreditAttribution: xlyz commentedsubscribing
Comment #17
sailtexas CreditAttribution: sailtexas commentedHi 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!
Comment #18
danielb CreditAttribution: danielb commenteddownloaded this module today
6.x-1.2
Comment #19
danielb CreditAttribution: danielb commentedI 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.
Comment #20
jleinenbach CreditAttribution: jleinenbach commentedIf 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.
Comment #21
ronan CreditAttribution: ronan commentedNope, it's still a feature request.
Comment #22
jleinenbach CreditAttribution: jleinenbach commentedWhich means that there is no PostgreSQL support.
Comment #23
danielb CreditAttribution: danielb commentedagree with jleinenbach, supporting the basic drupal requirements is not a 'feature'. This module literally does not work at all.
Comment #24
Charles Oertel CreditAttribution: Charles Oertel commentedHi 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
Comment #25
possum4all CreditAttribution: possum4all commentedCharles,
I get a "Could not complete the backup" error message when I try to use Advanced. Any ideas?
Comment #26
sense-designexactly the same message as possum4all, hope you have any ideas ...
Comment #27
suzanne.aldrich CreditAttribution: suzanne.aldrich commentedThis 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.
Comment #28
xavipal CreditAttribution: xavipal commentedI 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?
:(
Comment #29
threading_signals CreditAttribution: threading_signals commentedany progress on this feature?
Comment #30
Gallaecio CreditAttribution: Gallaecio commentedWondering the same...
Comment #31
jeff.esquivel CreditAttribution: jeff.esquivel commentedHi,
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,
Comment #32
ronan CreditAttribution: ronan commentedAweseome! 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
Comment #33
suzanne.aldrich CreditAttribution: suzanne.aldrich commentedSince 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.
Comment #34
jeff.esquivel CreditAttribution: jeff.esquivel commentedHi,
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,
Comment #35
ronan CreditAttribution: ronan commentedAwesome, 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
Comment #36
Anonymous (not verified) CreditAttribution: Anonymous commentedI'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.
Comment #37
threading_signals CreditAttribution: threading_signals commentedDon't forget to check your file permissions?
Comment #38
jeff.esquivel CreditAttribution: jeff.esquivel commentedHi,
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,
Comment #39
ogi CreditAttribution: ogi commentedsubscribe
Comment #40
Anonymous (not verified) CreditAttribution: Anonymous commentedSorry 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.
Comment #41
jeff.esquivel CreditAttribution: jeff.esquivel commentedHi 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,
Comment #42
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks 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.
Comment #43
threading_signals CreditAttribution: threading_signals commentedbytea_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
Comment #44
jeff.esquivel CreditAttribution: jeff.esquivel commentedHi 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,
Comment #45
Anonymous (not verified) CreditAttribution: Anonymous commented@vividgates
Thank you that fixed it!!!!
Comment #46
threading_signals CreditAttribution: threading_signals commented=)
Comment #47
andrew_k CreditAttribution: andrew_k commentedIt 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.
Comment #48
spatialguru CreditAttribution: spatialguru commentedSimilar 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 :)
Comment #49
threading_signals CreditAttribution: threading_signals commentedDon't change the version number, but start a new ticket, since this thread has patches for the 6.x version.
Comment #50
kmajzlik CreditAttribution: kmajzlik commented[34] seems to be working with latest stable (7.x-2.2) fine. Please try to commit it.
Comment #51
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #52
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #53
tamahome14 CreditAttribution: tamahome14 commentedUsed 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.
Comment #54
tamahome14 CreditAttribution: tamahome14 commentedCouldn't edit back from closed (fixed), selected by mistake...
Comment #55
tamahome14 CreditAttribution: tamahome14 commentedTrying 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.
Comment #56
Gaelan CreditAttribution: Gaelan commentedWell we're at it, let's add SQLite support too.
Comment #57
ronan CreditAttribution: ronan commentedComment #58
boabjohn CreditAttribution: boabjohn commentedVery 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
Comment #59
boabjohn CreditAttribution: boabjohn commentedHi 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
Comment #60
boabjohn CreditAttribution: boabjohn commentedAnd as far as I can tell, the patch at #34 is now outdated. Tried running the patch and it fails:
Comment #61
suzanne.aldrich CreditAttribution: suzanne.aldrich commentedI 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
Comment #62
junedkazi CreditAttribution: junedkazi commentedComment #63
slashack CreditAttribution: slashack commentedPatch for 7.x-2.8
I've just took patch from #34 and manually implemented it on current 7.x version.
Hope it helps.
Comment #64
sfcamil CreditAttribution: sfcamil commentedFatal 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 ...
Comment #65
sfcamil CreditAttribution: sfcamil commentedOk 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. ....
Comment #66
boabjohn CreditAttribution: boabjohn commentedLooks 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:
Any clues?
Comment #67
slashack CreditAttribution: slashack commentedNew 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.
Comment #68
AgentJay CreditAttribution: AgentJay commentedI'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.
Comment #69
AgentJay CreditAttribution: AgentJay commentedMy errors pointed to the fact that the queries that show the eventual tables/views:
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.
Comment #70
TurkishCoffee CreditAttribution: TurkishCoffee commentedI'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?
Comment #71
alienseer23 CreditAttribution: alienseer23 commentedHey 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.
Comment #72
slashack CreditAttribution: slashack commentedPatch from #67 still works on 7.x-3.1
Comment #73
DamienMcKennaThis appears to be working, but it hits an out-of-memory error:
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.
Comment #74
joel_osc CreditAttribution: joel_osc at OpenPlus commentedSeeing 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.
Can someone else give this a try?
Comment #75
DamienMcKennaI'd suggest checking out the PostgreSQL support for Drush's sql-dump command to get some ideas on how this could be handled better.
Comment #76
couturier CreditAttribution: couturier as a volunteer commentedThis 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
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.
Comment #77
couturier CreditAttribution: couturier as a volunteer commented@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?
Comment #78
DamienMcKennaLets work on fixing this as-is for D7.
Comment #79
DamienMcKennaComment #80
DamienMcKennaComment #81
DamienMcKennaComment #89
cmseasy CreditAttribution: cmseasy commentedPatch from #67 still works on 7.x-3.5, I did not test in dev.
No issues found.
Comment #90
joel_osc CreditAttribution: joel_osc at OpenPlus commentedSame for me, patch works great! Thank-you.
Comment #92
DamienMcKennaComment #93
DamienMcKennaRerolled.
Comment #94
DamienMcKennaComment #95
DamienMcKennaThis needs a reroll.
Comment #96
mrinalini9 CreditAttribution: mrinalini9 at Srijan | A Material+ Company for Drupal India Association commentedComment #97
mrinalini9 CreditAttribution: mrinalini9 at Srijan | A Material+ Company for Drupal India Association commentedRerolled patch #93, please review.
Comment #99
sanjayk CreditAttribution: sanjayk as a volunteer and at Srijan | A Material+ Company for Drupal India Association commentedComment #100
sanjayk CreditAttribution: sanjayk as a volunteer and at Srijan | A Material+ Company for Drupal India Association commentedLittle bit busy in next couple of days. Later will plan to work on it.