Our postgres data folder was installed on a drive with very limited space. I'm now trying to move it over to a newly mounted drive (more space). I've followed several blog posts and they all say...
stop service
copy data cluster
update postgresql-9.1 file (PGDATA=)
restart service
The service starts but when I go to connect, it gives me "could not connect to server: Connection refused"
I tried telnet-ing to port 5432 and nothing.
Here is the link to what I've been trying:
http://www-01.ibm.com/support/docview.wss?uid=swg21324272
Thanks everyone for your help. Looks like the problem was with permissioning.
Instead of doing
cp -R fromfolder tofolder
I did
cp -a fromfolder tofolder
And that solved it. Thanks all.
Related
I am new to pgAdmin 4. I have forgot to setup of login Email id and password while install pgAdmin 4. How can I change after installation? Any one can help me?
I'm assuming that since you don't remember your admin/password, you didn't do much with pgAdmin yet. If that's the case, you can move/remove the SQLite database out of the way and restart pgAdmin:
rm /var/lib/pgadmin/pgadmin4-server.db
or
mv /var/lib/pgadmin/pgadmin4-server.db /tmp
When you do this, you'll be prompted for a password the next time you start up the app.
You can also dump the contents of the SQLite database before moving/removing:
sqlite3 /var/lib/pgadmin/pgadmin4-server.db .dump
As my friend #Almadani and #richyen post are completely right.
But If you are working on remote host databases its best to delete that folder.Such as it may on some instance[ssh]
sudo rm -rf /var/lib/pgadmin
After deletion of folder. you can simply create new credentials
sudo /usr/pgadmin4/bin/setup-web.sh
You can also check it out from the blog.
By the way the blog is from here.
I solved this issue on Linux Fedora 32, and it's working. I hope you find it useful for you.
cd /var/lib/pgadmin4/
[root#localhost pgadmin4]# ls
pgadmin4.db sessions storage
[root#localhost pgadmin4]# rm pgadmin4.db
rm: remove regular file 'pgadmin4.db'? y
[root#localhost pgadmin4]# ls
sessions storage
there is still a way to find the database pgadmin4.db download and open this file via HeidiSQL as SQLite, directly viewing the table is not available - you can run the query SELECT * from user you will see your username, and if you do not remember the password can be changed to any known (encoded) - this method helped me
It was solved with me by removing pgadmin4.db, and run
python3.6 /usr/lib/python3.6/site-packages/pgadmin4-web/setup.py
and restart Apache web server, pgadmin4.
I am attempting to start a Postgres SQL server on amazon Linux using the command
sudo service postgresql start
I installed the server using this method. I have added it here for simplicity
sudo rpm -i https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-6-x86_64/pgdg-ami201503-96-9.6-2.noarch.rpm
and then
sudo yum install postgresql96-server.x86_64
after which i did this to install the command line tools for postgres
sudo yum install postgresql96.x86_64 postgresql96-libs.x86_64
Any suggestions on how I can start the server ? I usually start the server using
the command
sudo service postgresql start
however its not working in this case as it says "Unrecognized service"
I then tried this
postgres -D /usr/local/pgsql/data
postgres: could not access directory "/usr/local/pgsql/data": No such file or directory. Run initdb or pg_basebackup to initialize a PostgreSQL data directory.
Having the same issue, or similar. May be I installed pgsql from source, don't remember. We could make our own service start files. How? Let's find out! >>RTFM<< starting with what we already know:
man service
which leads us to chkconfig(8), so
man chkconfig
and it gives us an option
chkconfig --add ${svcname}
to add a brand new service under a name we choose!
But before we do, we might actually want to check what's already there. With
service --status-all
we get a list of all known services and their run status. And I found "postmaster" in my list, and as you might know, the PostgreSQL master server to connect to used to be called "postmaster". Yet, when I try
service postmaster status
it also tells me it doesn't know such service. OK, forget it -- for now -- just let's move on with making our own! But I still want to peek what there is in run-level 3 (normal server run level). So I go
ls -1 /etc/rc.d/rc3.d |fgrep post
and there I find: "K36postgresql95"! So, accordingly our service name should be "postgresql95". Trying that:
service postgresql95 status
it says now "postmaster is stopped". Confusingly the name the service reports for itself both in service --status-all and when we individually inquire for it is different than the name used to actually address it in the service command. Good to know. Easy enough to search /etc/rc.d for the name of interest.
service postgresql95 start
now starts the service. And check with
psql -U ${pguser} ${pgdb}
and I find that working. So now all I need to do is enable that service at system boot to auto-start
chkconfig --levels 3 postgresql95 on
and that works, doesn't it?
PS: It doesn't matter that I happen to run version 9.5
I recently installed PostgreSQL 9.2.24 on Amazon Linux 2 and I had to initialize the database manually before being able to create ROLE and DATABASE as I normally would on Ubuntu.
// initialize database after installing with yum
$ sudo postgresql-setup initdb
// start
$ sudo systemctl start postgresql.service
I have installed version 4-1.5, but when opening it, it always shows this error "The application server could not be contacted."
I removed the local directory hidden and resolved:
$ cd ~
$ rm -r .pgadmin/
Note: macOS Sierra (10.12.6) and pgAdmin 4-1.6. Also you are going to loose configuration data like database list tree, et al.
The Databases will remain intact since you are modifying/deleting PgAdmin related data not any of Postgresql itself.
I had the same issue, I fixed it by stopping the service in Postgres app, then start pgAdmin, and then start the Postgres service. I was able to connect it after that. Hope this help.
I had same error, but in my case I use wrong port number for the database
On my system Safari is the problem as it was default browser.
To fix, make Chrome your default browser and try relaunching pgadmin4
OR
Manually fix by
$ cat ~/.pgAdmin4.5704814747986328352.addr
http://127.0.0.1:62631/?key=0ec25e6a-dfe2-483e-9814-b315ea87c3cf
Paste what you get in Chrome
I am bashing my head against the wall. its been 4 days.but psql is not connecting.
We have a small array of Greenplum database.In that, We have the master node. when i am trying to use psql utility
Getting this error :
[gpadmin#master gpseg-1]$ psql
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
We tried
on searching for postmaster.pid files.
We have removed it.But still, error remains.
Use a command like ( netstat -ln; ps -ef ) | egrep '(postgres)|(postmaster)|(5432)' to try to determine whether or not an instance of the postgres server is running.
If the postmaster is not running, remove the postmaster.pid file and restart the database. While I don't use the Greenplum database, I see that instructions are here: Starting and Stopping the Greenplum Database. Do not remove the postmaster.pid file without making sure the database is not running, and note that removing the postmaster.pid file without starting the database is pointless.
It may be wise to open your postgresql.conf file and see if the listen_addresses, port, unix_socket_directory, unix_socket_group, and unix_socket_permissions settings might be a source of issues.
Since the error message referenced specifically mentions the socket file, look most closely at unix_socket_directory, unix_socket_group, and unix_socket_permissions.
If unix_socket_directory is pointing somewhere other than /tmp, then various workarounds exist.
Alternatively, and presuming that the server is running, one might try to locate the socket file without looking in the postgresql.conf file, though this might make it a bit harder to address permissions, port, etc. issues. A tool like locate, find, etc., may be used in conjunction with sudo or by the root user.
$ sudo find /tmp /var -name .s.PGSQL.5432
Presuming that the location of the .s.PGSQL.5432 file issue is the root cause of your problem, specifying the socket file location on the psql command-line is probably the most straightforward workaround. In example, if the *.s.PGSQL.5432 file is in /var/pgsql_socket directory as it is on some systems, try this, but, of course, use the actual directory where .s.PGSQL.5432 is located:
$ pgsql -h /var/pgsql_socket
If the .s.PGSQL.5432 file IS in /tmp, then the problem is more likely one of permissions, and consulting the postgresql.conf file is advised, and probably the user attempting the psql command will have to be added to a group that has access to the socket file. (Remember, log out and back in after changing group membership.)
Though the page does not necessarily seem to directly relate to this issue, do consider the Accessing the Database help as needed.
What does gpstate show? If it cannot connect, make sure the GPDB master is running:
ps ax | grep 'M master'
If the master is running, it will also show the port the master is listening on.
For the gpadmin Linux account, look in the ~/gpAdminLogs directory. There should be one or more startup logs that you can check.
That error normally means that the database is stopped. You should never remove this file unless it was left behind after a bad crash, where the file was never cleaned out. You would normally detect that situation when you start the db again - it would complain the file already existed.
I tend to look for
ps -eaf|grep -i silent
to see the postmaster processes.
If the master is down, but the segments are up, you will need to start the master only
gpstart -m
then stop everything with
gpstop -M fast
Causes for failures should be in $MASTER_DATA_DIRECTORY/pg_log and possibly in the corresponding segment pg_log directories. There may also be core files if the master or segments had a panic.
My app has fallen over as it can't connect to the postgres DB and when I try to connect to the DB via ssh and psql I get the following message:
psql: could not connect to server: Connection refused
Is the server running on host "<GEAR_ID>-<NAMESPACE>.rhcloud.com" (<IP_ADDRESS>) and accepting
TCP/IP connections on port <PORT_NUMBER>?
Running rhc app show --state prints:
Cartridge jbossas-7, haproxy-1.4 is started
Cartridge postgresql-9.2 is started
also, running rhc app show shows nothing unusual.
I can't telnet to the above IP_ADDRESS & POST_NUMBER, which kinda looks like communication has been broken between the 2 gears.
Any ideas?
I had the same problem. Using pg_ctl instead of the rhc commands fixed it for me.
$ rhc ssh <appname>
[...rhcloud.com ...]\> pg_ctl restart
pg_ctl: old server process (PID: 20034) seems to be gone
starting server anyway
server starting
To restart your entire application:
rhc app restart <app_name>
TO restart just your postgresql cartridge:
rhc cartridge restart <cart_type> --app <app_name>
You can get the cart type by running
rhc app show <app_name> --gears
And looking for the cartridge name under the "cartridges" heading
Ok, so I managed to work around this issue but man it was a PITA.
Since I couldn't find any useful help on the web around this problem, I've ended up creating a new app based on my old one, and using pg_dump and psql to save and restore the db from the old application into my new app.
I'm still none-the-wiser as to why the original app was no longer able to communicate from the main jboss gear to the postgresql gear, even though the postgres server was up and running.
Perhaps (hopefully) someone from openshift will want to look into this. If so I'll keep my old broken app around for a while.