I am trying to download the dump of a database on Heroku in the following way:
pg_dump dc6psqngs8h580 -h url_address -U user_name> db.sql
but I am getting this error all the time:
pg_dump: server version: 9.2.4; pg_dump version: 9.1.5
pg_dump: aborting because of server version mismatch
I found topics with this error here on SO, but none of them helped me out with this issue.
I added:
PATH="/Applications/Postgres.app/Contents/MacOS/bin:$PATH"
into ~/.profile, also I added
export PATH=/Applications/Postgres.app/Contents/MacOS/bin:$PATH
into ~/.bash_profile, but none of these helped me to successfully download the dump.
Where can be yet the problem and how to fix it?
Thank you very much
Install PostgreSQL 9.2.x whether by homebrew, from source, or some other means.
Basically you can dump an older server with a newer version of the dump file, but not the other way around. This exists to ensure that newer features of the db are not ignored in the dump and there are no command line switches to get around the error.
Related
Trying to make a SIMPLE backup of our Redis Database that is on Heroku for a Ruby on Rails command, I connect using redis-cli just fine, I can type help save and it says it is a command, but when I try to run save it gives me a lame error that says:
ec2-34-231-26-8.compute-1.amazonaws.com:19099> save
(error) ERR unknown command `save`, with args beginning with:
ec2-34-231-26-8.compute-1.amazonaws.com:19099> bgsave
(error) ERR unknown command `bgsave`, with args beginning with:
ec2-34-231-26-8.compute-1.amazonaws.com:19099>
Yet if I ask for help on these commands they do in fact exist:
ec2-34-231-26-8.compute-1.amazonaws.com:19099> help save
SAVE -
summary: Synchronously save the dataset to disk
since: 1.0.0
group: server
ec2-34-231-26-8.compute-1.amazonaws.com:19099> help bgsave
BGSAVE -
summary: Asynchronously save the dataset to disk
since: 1.0.0
group: server
ec2-34-231-26-8.compute-1.amazonaws.com:19099>
Does anyone know why Redis doesn't work properly?
It is the Heroku Hobby Dev version and I am connecting to it via Windows which is not giving me ANY trouble at all other than the Redis Server not working properly. On another instance I get an even stranger error that says Save is not allowed?
I have searched for hours and there appears to be NOTHING on this subject at all which is very confusing to me. A lot of the commands listed on redis.io return that same stupid error that the command doesn't exist when the help clearly states that it DOES exist.
Any help would be appreciated..
I hope this may help someone, In my case was that there was a rename in the configuration
check your redis.config file
I had
rename-command SAVE "SV"
now, type your rename command and that's it
127.0.0.1:6380> SV
OK
I am trying to connect to an Vertica DB from R using "RODBC" package. Also, the machine I am using is an remote server which doesn't have direct internet access so I basically "transfer" all source files from my local to the remote server to build the system. So, in order to give you an clear context, I am listing all my steps in attending of installing "RODBC" package below:
Step1 - I downloaded the RODBC_1.3-13.tar.gz source file for RODBC and then tried to directly install it with "R CMD INSTALL". However, I encountered error as "ODBC headers sql.h and sqlext.h not found".
Step2 - After a few researches, I found that the installation of "unixodbc-dev" would potentially solve this issue. Therefore, I downloaded all needed dependencies for "unixodbc-dev" and transferred them to the server. As you can see the list:
Therefore, I also successfully installed "unixodbc-dev":
However, another error message appears when I tried to re-install the "RODBC" using "sudo R CMD INSTALL /home/mli/RODBC_1.3-13.tar.gz" in which it returns error "no ODBC driver manager found":
As the message indicates, the installation program can't locate my ODBC driver manager. So, I downloaded "vertica-client-7.2.3-0.x86_64.tar.gz" and unzipped it on the server:
So, now my question is how can I customize the "R CMD INSTALL" command say, using some parameter handles to direct the installation program to locate the driver manager? Or am I trying this in a right direction? Please let me know. Any help would be really appreciated!!! :)
ADDITION:
I have also tried it with JDBC in which the I successfully loaded the "RJDBC" package in R and used the JDBC driver from vertica-client-7.2.3-0.x86_64.tar.gz. Also, I have already had "rJava" installed. However, I have still got an error when I tried to make the connection. I am listing my result below:
I successfully installed the "RJDBC" with "$R CMD INSTALL RJDBC_0.2-5.tar.gz --library=/usr/local/lib/R/site-library/" and then I tried the following scripts in R. All the lines are successfully executed except on the line 16:
Based on the error message, I assumed the version of the JDBC driver that I was using is too new for the Vertica server. So, I was trying to use an older version JDBC driver instead, like the "vertica-jdk5-6.1.0-0.jar" which I have downloaded from this link:http://www.java2s.com/Code/Jar/v/Downloadverticajdk56100jar.htm
So, I moved the file "vertica-jdk5-6.1.0-0.jar" to my home directory on the server and then changed the JDBC driver path in the R script:
As you can see, it still returns error "FATAL: Unsupported frontend protocol 3.6: server supports 3.0 to 3.5". Am I doing it right? Or is there an issue with the new driver that I downloaded? How can make it works? Please, any help will be really appreciated! Thanks!!!
A few things:
First, just do sudo apt-get install r-cran-rodbc. The package was created (by yours truly) in no small part because dealing with unixODBC or iODBC is not fun. But even once you have that, you still need the ODBC driver for Linux from Vertica. And that part is filly.
Second, I just did something similar the other day but just used JDBC, which worked. You do of course need sudo apt-get install r-cran-rjava which has its own can of worms (but I already mentioned Java...) Still, maybe try that instead?
Third, you can cheat and just use psql pointed to the Vertica port (usually one above the PostgreSQL port).
I've been using elementary OS 0.3 Freya (64-bit) built on Ubuntu 14.04
When I tried to open Software Updater its showing Failed to download repository information
and when I tried to run
sudo apt-get update
this is what it prints:
W: Failed to fetch http://in.archive.ubuntu.com/ubuntu/dists/trusty/Release Unable to find expected entry 'restricted/source/Sources' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
I donno whats the problem and I cann't find a solution for this while I googled it.
From what I've read on the issue, one of the repositories has failed. Maybe try removing them one at a time and see if you can find the offending one.
Edit the ppa's and change freya to trusty. Not sure if this is the ideal solution, but it fixes it.
I removed Chrome download/update from the download list and changed the Ubuntu Software Settings in column 1 to Download from main server. It did the download and update this way.
Jupitor$ bundle exec rake db:create db:migrate
APP_development already exists
rake aborted!
PG::Error: ERROR: invalid value for parameter "TimeZone": "UTC"
: SET time zone 'UTC'
I keep getting this error when trying to migrate to my postgres database.
help would be much appreciated!
I had the same problem using the Postgres.app from Heroku. Rebooting my Mac solved it.
Restarting postgresql works.
To restart if you've installed it using homebrew, brew info postgresql will tell you to:
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
brew services restart postgresql
Try restarting the server. I updated Postgresql through Homebrew but forgot to restart the server and got this same problem. I believe it's due to the client and server versions not matching. psql started with:
$ psql
psql (9.1.4, server 9.1.2)
Type "help" for help.
Based on #MathiasJ's answer, instead of rebooting my entire machine, I ran
brew services restart postgresql#9.6
and my subsequent rake db:create worked perfectly.
I don't think I deserve any points for that but rebooting my Postgres.app (which is better than rebooting the whole system) solved it for me. The app doesn't show up on the Dock, you can find it on the navbar at the top of your window. Hope it helps anyway.
What actually happened is that you upgraded the postgresql server and cleaned-up your old folders but you haven't restarted your postgresql server. The server searched for the timezones files in the deleted dir
If nothing else fixes and you happen to be using homebrew, chances are you have issues with current links.
Assuming you have two Postgres versions installed, make sure you unlink and then link again. In my case, I needed the two versions working in order to run pg_upgrade. I have postgresql95 and postgresql so I did:
$ brew unlink postgresql
$ brew unlink postgresql95
$ brew link postgresql95
$ brew link --overwrite postgresql
That got me both working at same time. Hope it becomes helpful as it took me a good while to figure that out!
I also had this problem.
Login to the database then issue:
set time zone utc;
In my case restarting the database didn't help. Updating tzdata (apt-get install tzdata) did the trick for me.
just restarting the database helped. Homebrew updated my Postgres installation and I did not restart yet.
I had a similar problem after updating time zone information, that is, downloading the IANA database and compiling using zic.
My problem actually began after restarting PostgreSQL. I got invalid value for parameter TimeZone: UTC and restarting again did nothing to solve the problem.
It turns out my time zone information was completely messed up after the update. I had dangling symbolic links in /usr/share/zoneinfo. From a psql console, I got:
mydb=# SELECT * FROM pg_timezone_names;
ERROR: could not stat "/usr/share/zoneinfo/PRC": No such file or directory
I deleted all such dangling symlinks. After doing this, at least I could get SELECT * FROM pg_timezone_names to work, but still got the same invalid value... error.
What finally solved the problem for me was creating a new symlink:
cd /usr/share/zoneinfo
ln -s Etc/UTC UTC
After this, SET time zone 'UTC' worked correctly.
brew services restart postgresql did not fix for me. I'm sure rebooting would've worked, but I wanted to figure out the cause of the issue.
I believe the issue was caused for me because of two conflicting versions of postgresql.
I already had postgresql running with brew services, and then installed postgresql#11 which left postgresql running in brew services even after I uninstalled postgresql.
I fixed this by stopping the postgresql brew service, even though it wasn't listed in brew services list.
Steps to reproduce:
$ brew install postgresql
$ brew services start postgresql
$ brew install postgresql#11
$ brew uninstall postgresql
$ brew services start postgresql#11
How to fix:
$ brew services stop postgresql
Update: issue appears to have been deleted.
Opened an issue on Homebrew requesting that a formula's service should automatically be stopped upon uninstall.
Just a quick reference for those that are not using Postgres.app, but that start psql from the command line or through launchctl. You'll need to adjust the following for where you have your Postgres data and log files located at:
pg_ctl stop
pg_ctl start -D /usr/local/pgsql/data/ -l /usr/local/pgsql/log/server.log
For everyone using homebrew.
brew services restart postgresql did not fix for me too.
Rebooting fixed the issue. Thank you #JBallin, what you said is right.
Apparently, a similar thing also happens with Java/JDBC while connecting to Postgres.
The solution there is to tell JDBC to report the correct user timezone to Postgres while getting the connection.
So, explicitly mention the user timezone while starting the program helps:
java -Duser.timezone=America/Los_Angeles com.example.MyMainClass
Note:
Adding this here because this happens to be the first result on Google for this issue with connecting to Postgres!
Source:
This comment by Yuriy on the Jira support forum:
https://community.atlassian.com/t5/Jira-questions/invalid-value-for-parameter-quot-TimeZone-quot-quot-US-Pacific/qaq-p/839426
I'm trying to give pg_bulkload a try.
When I try to use the postgresql executable it provides, I get the following error:
/usr/local/src/pg_bulkload-3.0.1/bin> ./postgresql start -D /pg_data
server starting
/usr/local/src/pg_bulkload-3.0.1/bin>
FATAL: unrecognized configuration parameter "wal_level"
Google turned up an exact match for this error when someone was using a 9.0 version of psql to run a script on an instance of Postgres 8.4. I don't see how that could be related to my case--I have two versions of Postgres, but I'm sure I'm pointing at the right directory... any thoughts are very welcome.
As far as I can tell from the docs, PostgreSQL 9.x supports a configuration parameter named "wal_level", but version 8.4 does not. The postgresql.conf file for my 9.0.something server has that parameter; the one for my 8.4 server does not.
PostgreSQL 9.x server configuration
PostgreSQL 8.4 server configuration
Your error message suggests you're running version 8.4, but it's reading the configuration file for a 9.x server. Check your postgresql.conf and installation process. I'm thinking pg_bulkload might have "helped" you in ways you didn't anticipate.
I think that it can be a bit tricky to install pg_bulkload to the right place if you have more than one version of PostgreSQL installed on your machine. My first problem was that pg_bulkload (version 3.1.6) could not find pg_port library. I copied the library libpgport.a (a static library) to /usr/local/lib where it was found, but this approach is not recommended, because this is only a quick fix that doesn't work at the end. So, very soon there was another problem: "undefined reference to `pstrdup'". I reckon that in pg_bulkload there should be a possibility of pointing out where PostgreSQL is installed. Well, I changed Makefile of pg_bulkload in pg_bulkload-3.1.6/bin, namely line with PG_LIBS: PG_LIBS = $(libpq) -L/current location of your PostgreSQL/PostgreSQL/pgsql/lib -lpgport -lpgcommon. -lpgport has to be added before -lpgcommon. Last but not least, to compile and install pg_bulkload you shoud modify your PATH: PATH=/current location of your PostgreSQL/PostgreSQL/pgsql/bin:$PATH make USE_PGXS=1 [install]; This makes sure that your pg_bulkload will be added to the correct version of PostgreSQL (in my case 9.3). Enjoy!