I just downloaded and installed PostgreSQL from here
https://www.enterprisedb.com/downloads/postgres-postgresql-downloads
I wanted to create my first server but I get this error
'utf8' codec can't decode byte 0xfc in position 36: invalid start byte
My pg service is running automatically
What am I missing?
Same thing here (postgresql 9.6 on windows) when I tried to using query tool.
It's happend after I changed postgres user password using pgadmin 4.
I simply restarted the postgresql service, started pgadmin 4 and then it asked for the new password. After typed it, no more error message.
I just installed PGADMIN version 4.11 in windows 10 and the issue persists...
So I shut down the PGADMIN instance in the task-tray and started it again from the start menu.
Typed the 'master password' and voila, it is working.
Try to add the following line at the end of the data\pg_hba.conf file and then restart the PostgreSQL service.
host all all all md5
Good luck.
This has been fixed with pgAdmin4 v3.0.
Could you try downloading the latest version of pgAdmin4 & Check?
https://www.pgadmin.org/download/
Related
I tried to make a backup with Postgres 11.1 in pgAdmin4, but it failed.
pgadmin displayed a window with
Status: Failed (exit code: 1).
pg_dump:server version: 11.1; pg_dump: 10.5
pg_dump: aborting because of server mismatch
I don't really understand it. Does pgadmin4 not know that I am using 11.1 and not 10.5?
PROBLEM SOLVED - IN MY CASE.
Go to
pgadmin < Preferences < Path < Binary Path
The PostgreSQL Binary Path was set automatically to $DIR/../runtime
I changed the Path to my installed PostgreSQL Version C:\Program Files\PostgreSQL\11\bin
Your pgAdmin is using PostgresSQL client v10, but your server is v11.
Since v10 cannot know how to correctly dump a v11 database, it refuses to try.
Use a more recent version of pgAdmin!
I have installed the solr service on a LINUX environment. Now trying to start the service using the below command
service solr start
After executing this command, am getting below error from the server
Waiting to see Solr listening on port 8080 [-] Still not seeing Solr listening on 8080 after 30 seconds!
tail: cannot open `/var/solr/logs/solr.log' for reading: No such file or directory
I created the solr.log file manually and placed it under the above mentioned path, But as soon, i issue the command "service solr start" . The solr.log file will be renamed and there won't be any new file created with the solr.log. hence the service fails to start. Could anyone let me know how to tackle this issue.
Thanks in advance.
I had a similar issue, and was able to find a hint in the /var/solr/logs/solr-8983-console.log
Originally I had been using Java 8, and Solr was working just fine for me.
When I switched to Java 11, Solr would have the issue you reported.
The log file contained the following:
Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Unrecognized VM option 'UseParNewGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I switched back to Java 8 and Solr started just fine.
First, did you use the procedure provided to install the Solr service page 461
Second, did you set the proper overrides to the environment defaults in a solr.in.sh script (p. 462 of the ref manual). You also need to make sure that the LOG4J_PROPS in the solr.in.sh file points to your log4j.properties file. Also make sure that SOLR_LOGS_DIR is pointing to the correct place.
If all that is correct, then check that the values in your log4j.properties file are set correctly (p. 468 of the ref manual).
You can get the reference manual here: https://www.apache.org/dyn/closer.lua/lucene/solr/ref-guide/ if you don't have it already.
I had a tough time getting Solr to run as a service, but in the end I simply wasn't reading carefully enough.
I have to take backup of my database but when I right click DB and then backup The button for backup is disabled. Similarly in existing database ,not able to restore because the Restore button too disabled.
I was working fine till the time I created a new database.
How do they get enabled?
I had the same problem in ubuntu 14.04. It was necessary to install both postgresql-client-common (which contains pg_dump and pg_restore) and postgresql-client packages.
There is no need for reinstall,
just open File->Options->Binary paths and add set "PG bin path" to path where pg_dump/pg_restore is located.
Here is a solution:
$ yum install postgresql-contrib
Problem could be caused by a fact that you simply do not have pg_dump and pg_restore tools installed (or they are not visible for pgadmin).
This had happen to me when installing pgadmin3 on CentOS 7 via PostgreSQL yum repository. To resolve this I had to install package with those tools - in my case postgresql94 (PostgreSQL client programs and libraries).
On other distros you will need to find which package should be installed. AFAIK this issue is not present in Windows environment, pgadmin installer probably have all needed dependencies.
I was facing problem in restoring my database from backup, so I followed some steps:
Go to c:\ drive and find this path "C:\Program Files\PostgreSQL\13\bin"
Copy all the files from there then
past all the copied files to the given folder
"C:\Program Files\PostgreSQL\13\pgAdmin 4\runtime"
Your problem will definitely be solved.
You can go and check my video Where I showed step by step problem.
[link]
(https://youtu.be/GS3Dg0TfyFI)
Just reinstall your PGAdmin3.
We had the same problem on a Mac and after reinstallation, the right click menu showed more options like "Restore" and "Backup".
I had this issue (restore button disabled) and the problem was a corrupted dump.
So, I've created a new dump and tried again. After selecting the new file, the button became available.
in my case i'm on windows,
if python isn't installed, install it.
restart, and you're done.
I have checked in the pgadmin4 sql:
SELECT * FROM pg_available_extensions;
and got the current installed 2.1 which is not correct. You need to check on the db command line, the same query did result that the adminpack is NOT installed.
Solution: Logon to the DB on comand line and write
CREATE EXTENSION adminpack;
I'm trying to export my database, using MySQL Workbench 6.0 on Windows, to send to my db instance in Amazon RDS, but i'm getting this error:
Operation failed with exitcode 7
11:34:40 Dumping clubbin (taxicompanies)
Running: "C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqldump.exe"
-defaults-extra- file="c:\users\selene\appdata\local\temp\tmp6o0hno.cnf"
--max_allowed_packet=1G --delayed- insert=FALSE --host=localhost --user=root
--port=3306 --default-character-set=utf8 "clubbin" "taxicompanies"
mysqldump: [ERROR] unknown variable 'delayed-insert=FALSE'
Does anybody have any idea that can help me?
mysqldump: [ERROR] unknown variable 'delayed-insert=FALSE'
This error occurs on various systems and can be temporarily fixed by:
Going to the appropriate directory depending on the system:
a) Windows: C:\Program Files\MySQL\MySQL Workbench 6.3 CE\modules (32-bit installation on x64 systems: C:\Program Files (x86)\MySQL\MySQL Workbench 6.3 CE\modules)
b) Mac OS X: Applications/MYSQLWorkbench.app/Contents/Resources/plugins - right click on the app and select Show Package contents to get inside the app (thanks to Bradley Flood)
c) Linux Ubuntu: /usr/lib/mysql-workbench/modules (thanks to Alessandro Lopes)
Open file wb_admin_export_options.py
Find line "delayed-insert":["Write INSERT DELAYED statements rather than ...
Insert # at the begin of this line to comment it out
Save file and restart Workbench.
Tested on Windows 7 x64, MySQL 5.6.27 (MyISAM) & Workbench 6.3.5 x64.
Tested on OSX Yosemite 10.10.4, MySQL 5.5.27 (MyISAM), Workbench 6.3.5 build 201 CE x64.
This worked for me.
Edit the file C:\Program Files\MySQL\MySQL Workbench 6.3 CE\modules\wb_admin_export_options.py (make sure you open your editor as administrator)
find the line:
delayed-insert":["Write INSERT DELAYED statements rather than INSERT statements.","FALSE", "BOOL", ("5.0.0", "5.7.0")],
and put a hash “#” at the beginning of the line so that it looks like this:
# delayed-insert":["Write INSERT DELAYED statements rather than INSERT statements.","FALSE", "BOOL", ("5.0.0", "5.7.0")],
This will comment the line out so that Workbench won’t use this statement.
Save and close the file.
Start Workbench and try again.
Reference http://dannytsang.co.uk/mysql-workbench-error-code-7/
On Linux Ubuntu/Mint:
The config file is located at :
/usr/lib/mysql-workbench/modules/wb_admin_export_options.py
As described by c4pricorn, simply comment the line "delayed-insert":["Write INSERT DELAYED statements rather than...
And restart workbench.
Delayed inserts where deprecated in 5.6 and are converted to normal inserts in 5.7 (see also http://dev.mysql.com/doc/refman/5.7/en/insert-delayed.html). I wonder why mysqldump reports an error on this. Regardless, MySQL Workbench must be adjusted to no use delayed-insert for dumps. Can you please file a bug report at http://bugs.mysql.com to bring this on the agenta for MySQL Workbench?
In CentOS 7,
Open file /usr/lib64/mysql-workbench/modules/wb_admin_export_options.py
Find line "delayed-insert":["Write INSERT DELAYED statements rather than ...
Insert # at the begin of this line to comment it out
Save file and restart Workbench.
As highlighted at an earlier post, by putting a # at the delayed-insert line in wb_admin_export_options.py does solves the problem.What i like to add is that when i tried to edit it in notepad and Pythonwin,i encountered the admin rights issue.They don't let me save the file after my edit.I finally work around it by editing and saving it in notepad++.One can download it from here https://notepad-plus-plus.org/
Removing delayed-insert line in wb_admin_export_options.py solves the problem. You need to get admin rights to modify the file.
Nonetheless consider that your MySQL database might have been not properly upgraded before.
Be careful on editor: on Win7 64 notepad doesn't work on this modification.
Notepad will present a single line, use an editor with crlf.
I had this error until I upgraded to the latest version. Currently 8.0.15. That fixed it on my Mac.
I'm using Collabnate Subversion Edge.
I'm getting below error when trying to access URL http://localhost:3343/csvn.
Collbnate is set up on Windows Server 2008.
HTTP ERROR: 503
Problem accessing /csvn/. Reason:
Service Unavailable
Powered by Jetty://
How to solve it?
I spent two days fighting with the same problem. It turned out that CollabNet Subversion Edge 4.0.11 does not support Java 8.
The following procedure helped me make CN Subverion Edge 4.0.11 work again on Windows 7:
1) Uninstall CollabNet Subversion
2) Uninstall Java 8 (I had Java 7 and 6 side by side, so after uninstalling the 8, 7 picked up after I added it to PATH variable. It is important to add it at the very beginning of the path, otherwise Windows\System32\java.exe will be taken, which was not good for me also)
3) Install CollabNet Subverion (the important thing is to uncheck the "Run CollabNet ..." check box in the final screen. It looks like the installer is still creating files at the end and only after I have clicked OK in the final screen the needed configuration files have been created in data/conf folder.
4) Make sure that data/conf/httpd.conf file is created. If it is there, got to services (services.msc) and start server manually
Now launch the browser and navigate to localhost:3343/csvn.
Good luck.
1) Install Java 7
2) In file \csvn\svcwrapper\conf\wrapper.conf change from #wrapper.java.command.maxVersion=1.6 to wrapper.java.command.maxVersion=1.7
3) Run \csvn\svcwrapper\bat\runConsole.bat
Good luck.
Check in c:/csvn/data/logs for a log that starts with "console". Then find the error(s) and check what is wrong.
Did you try restarting the service ?
I had the same issue, CollabNet Subversion Edge version 4.0.4. In my case the problem was updating the JAVA_HOME from JDK 1.6 to JDK 1.7.
I finally resolved it changing the file:
C:\PROGRA~1\csvn\svcwrapper\conf\wrapper.conf
I changed the value of the property: wrapper.java.command:java
wrapper.java.command=C:/PROGRA~1/Java/jdk1.6.0_45/bin/java
So the csvn now runs with 1.6 as before. And it works again as a service automatically.
Good luck!!
There's an alternative issue that results in the same error: The database may get corrupted. This is what just happened to me. The above answers where not working in this case. As Subversion Edge 5.0.1 comes bundled with jre8, it would be rather strange if it weren't able to run against it.
To solve the problem, I had to patch the database (luckily, the user database c:\csvn\data\csvn-production-hsqldb.script is a plain text sql file).
Backup files in c:\csvn\data
Delete csvn-production-hsqldb.script and start the service (should come up now)
Exit the service
Save the file which is automatically recreated now
Compare your old file and the new working one
Replace every line starting with INSERT INTO QRTZ in your database with the corresponding lines from the working copy
Copy the new files to the proper place
Start the service
Hope it worked
I had this problem too. Upgrade to SubversionEdge 5.1.4 solved the issue.
We encounter this problem with CollabNet Subversion Edge 3.3.1 every time we patch our JDK 6 install (e.g. IAVM update). We need to install JDK 7 and 8 on this machine also so the installers are confusing the version information in the Windows Registry (not too much of a surprise there). Even if we update JDK 6 last, it gets weird too.
Nevertheless, it turns out the Subversion Console uses the Windows Registry to locate the Java install to launch the Console service. Updating the registry entry HKLM\SOFTWARE\JavaSoft\Java Development Kit\CurrentVersion to 1.6 and having a proper install of JDK 1.6 will restore console operation.