I've been having a bit of trouble trying to install PostgreSQL 14 for the first time.
I would like to apologize in advance if this question has been asked in the manner that I am about to ask it, but I do not think it has. If it has been, please direct me to the appropriate location!
I've done a fair amount of Googling on the matter, and all the information that I find seems to be rather fragmented, or I end up following a spaghetti trail of hyperlinks (a la-do-this-and-follow-this-other-link-with-more-information-than-you-need-to-understand-this-other-required-portion).
Personally, I don't want to jump around to 50 different locations on the web to try and conjure up a piecemeal solution that I believe works, only to be proven wrong later. I want to know what to do and why it works. I've tried reading the documentation, and have given up on it, because to me, it seems to assume that the server has already been set up by a database administrator.
Instead of articulating my problem directly (as I seem to be having more trouble than I would like by trying to do so), I believe it would be easier to articulate my problem indirectly by stating what my expectations would be after installing PostgreSQL for the first time.
So to start, I will mention that I'm running Ubuntu 18.04.6 LTS, and am installing PostgreSQL 14.1 with the following command:
sudo apt install postgresql-14
Before continuing, I would like to add a side note in advance, that I do not want suggestions for an alternative OS or install method. I just want to be able to get "up and running" in a common-sense fashion from this exact point.
Moving on, I know that the aforementioned command creates a *nix user called postgres.
From here, I can now indirectly state my problem using an outline of what my goals and expectations are immediately after installing the software via that command.
After installing PostgreSQL via apt, these are my expected goals:
I want any client to be able to connect to the database server from any computer where a route exists from the client to the server.
For the sake of simplicity with these stated goals, when it is directly or implicitly stated that I am trying to connect a client to the database server, I am making the assumption that the client is able to, at a minimum, ping the machine that the server is running on, and vice versa.
For now, I'm not completely worried about the database being accessible from the public Internet.
I expect to be able to access the database from any computer on my LAN, whether it is an actual LAN, or some sort of logical LAN (like a WAN or a VPN).
If I change the PostgreSQL password of the postgres user, I expect that any client logging into the database server via the postgres user will require the password.
This means if I want to change the password to some_password via \password postgres or ALTER USER postgres WITH PASSWORD 'some_password'; (I am assuming this is how you change the login password of a PostgreSQL user), then...
I expect running psql [-h host] -U postgres -W from any host...
That when I am prompted to enter the password...
I can only log in by entering the exact password of some_password.
Entering any other arbitrary text for the password should not allow me to log in.
I am adding this as a requirement because previous install attempts have shown me that this is NOT the case.
I expect to be able to create a PostgreSQL user account other than postgres (e.g. db_user) with a password and have it be subject to the same requirements as the postgres user.
i.e. once the new account is given permission to log in, the same common-sense login requirements to log in must be imposed, i.e. you can't get in if you don't have the correct username/password combination.
If the process to achieve the aforementioned can be explained in such a way that it can be understood with minimal mental friction, I would be extremely grateful.
Feel free to assume that my knowledge is on par with that of a undergraduate CS student who just completed their first year of university, who also understands Linux filesystems and basic computer networking. I just want the answer to be as accessible to as many people as possible, as I am sure I'm not the only person who has struggled with installing PostgreSQL, in spite of having a power user's level of computer literacy.
sudo apt install postgresql
sudo -u postgres psql
Set a password for this user with \password or the other method you mention
sudo vi /etc/postgresql/10/main/pg_hba.conf
Make the only uncommented nonblank line in this file be host all all all md5
sudo vi /etc/postgresql/10/main/postgresql.conf
uncomment listen_addresses line and set it to '*'
sudo service postgresql restart
When you make a new user, you should also make a new database which has the same spelling as the user does. Otherwise you will need to specify the database name when you try to log in with psql -U, such as psql -U newname -d postgres -h[hhh]. Should you actually be running 14 not 10, then you will need to change the paths of the config files you need to edit accordingly.
Using Manjaro, I freshly installed PostgreSQL with an user-defined data-directory. PostgreSQL is running fine, but I can't find the postgresql*.log(s), which I used to find in /var/log/postgresql on my former system. In ksystemlog I've seen an error, that I forced by
select * from non_exist_table;
but I'm wondering, if there is no longer the postgresql*.log.
Thank you!
Here is my postgresql.conf.
With logging_collector=off, the logs will just spew to the stderr of the postmaster process. That could have been redirected to a file, or just going to some tty someplace, or just be thrown away. You would have to look at the code which launches the database server.
I have attempted to install PostgreSQL 9.4 and 8.4 multiple times and it is failing no matter what I have tried. I am attempting to install on Windows 7 SP1 x64. After each failed install I have uninstalled and deleted the installation folder to start fresh.
Each time I attempt the install I get an error pop up near the end of installation that says:
"failed to load sql modules into the database cluster".
Then another error pop up displays immediately after that says:
"Error running post install step. Installation may not complete correctly. Error reading C:/Program Files/PostgreSQL/9.4/postgresql.conf"
I have attempted installation with the following actions:
Always installed as administrator
Turned off all virus protection and windows firewall
Changed the installation directory to something other than the Program Files directory.
Changed the data directory to something other than the installation directory of postgres
None of the actions above have helped and I always receive the error. Any help that someone can provide would be greatly appreciated!
Encountered a very similar problem that OP is reporting today while installing Postgres 9.4.
It turns out that the password generator I was using has made a password that contains non-alphanumeric characters. ("^") I believe was the culprit in this case. Removing that allowed the installation of Postgres 9.4 (Windows 64 bit) to complete.
Very easy fix once you've found it, but the error message that comes up is not descriptive, so in this case I didn't notice at first what I was doing wrong.
I was getting this same error when trying to install PostgreSQL v9.4.4 on Windows 10 Pro. Starting with a solution hosted on Stack Exchange, I came up with the following steps that allowed the installer to run successfully:
1) Create a new user account, called postgres
2) Add the new account to the Administrators and Power Users groups
3) Restart the computer
NOTE: I added step #3, since step #4 didn't work without it
4) Run a command prompt as the postgres user, using the command:
runas /user:postgres cmd.exe
5) Run the installer from the postgres command window
6) Delete the postgres user account, as well as the user directory
NOTE: I added step #6, since the postgres account is not required after installation
What worked for me is, during the install, specifying a Postgre SQL data folder that's outside of any Windows user profile directory (C:\Users), such as C:\postgres-data.
My setup:
Win 10 Pro
PostgreSQL 9.5 RC1
I ran into this issue when I tried setting PostgreSQL's data directory somewhere under my user profile's directory, such us somewhere under "My Documents".
I tried Jeff G's solution and it didn't work at first. It worked only when I kept the data directory as the default (C:\Program Files\PostgreSQL\9.5\data). So then I tested further and tried setting the data directory to somewhere outside of any user profile directories (i.e. somewhere that isn't under C:\Users). For example, C:\postgres-data and this worked.
I then just tried using that directory with my default user, and not bothering with the postgres temp user as outlined in Jeff G's solution and that also worked. So in the end, it had to do with my data directory being somewhere under C:\Users. As long as it was outside of that, it worked.
None of these answers here helped me, finally I solved this problem by creating the folder before the installation (C:\PostgreSQL\data) and giving it full access for the group "Users".
Windows 7 x64, postgresql-9.5.2-1-windows-x64
Hope It's Work.
1.)Uninstall PostgreSQL
2.)Delete the postgres user if it still exists :
net user postgres /delete
3.) Create the postgres user with a password you can remember:
net user /add postgres
4.) Add the postgres user to the Administrators group:
net localgroup administrators postgres /add
5.) Add the postgres user to the Power Users group
net localgroup "power users" postgres /add
6.) Run a command window as the postgres user:
runas /user:postgres cmd.exe
7.) Change user postgres and install postgresql
8.)Back your and remove the postgres user from the Administrators group.
net localgroup administrators postgres /delete
I had the same error ("Failed to load SQL modules into the database cluster.") when installing on W2K12R2 using the EnterpriseDB installer linked to from the PostgreSQL Windows download page. I tried running the installer with admin privs, and using the postgres-user solution offered by Jeff G, but neither worked. Finally I tried the second installer, BigSQL, and that installed without issue.
When installing PostgreSQL, do not use the following symbols in your database's admin password: %, <, and >.
Bug report and problem solution here
Changed the data directory to something other than the installation directory of postgres
Make sure NETWORK SERVICE has read/write permissions on that folder, the installation was failing for me until I did this.
I had this issue too with 9.5 and got around it by:
Installing with the default data folder.
Making sure my new data folder had full control access for the "NETWORK SERVICE" account.
Then changing the default PGDATA folder as per this instruction: https://wiki.postgresql.org/wiki/Change_the_default_PGDATA_directory_on_Windows
I had the same problem, and noticed that some Postgres .bat files were opening in a text editor. Text editors opening files during installation isn't too uncommon, but I noticed these batch files were setting directory permissions. I then found that .bat files were set to open in a text editor (Notepad++) by default. I changed the default program for .bat files, uninstalled Postgres, re-ran the installer, and it worked perfectly. Hope this helps.
I had the same problem before. I solved this by installing Visual Studio C++ Express first.
I had the same experience as #gomisha. #Jeff G's solution did not work for me no matter which user ran the installer.
As long as the target data directory was anywhere under c:\users, the install or database cluster init would fail.
I was successful after creating c:\postgresql-data and ensuring that the postgres user had full access in the 'effective access' tool.
Note: I did not use control userpasswords2 to set up the postgres user; I did it through the traditional crappy Windows 10 user wizard that tries to make the user sign up for hotmail. I did run the install as postgres.
I was getting this issue with the BigSQL windows installer PostgreSQL-9.6.5-1-win64-bigsql.exe
The problem turned out to be that my system path was too long. After removing some uncessary junk from my System Path, and then reinstalling, the problem was gone.
One of the answers here is the only thing that worked on my machine:
I had the same error message when trying to install 9.2.4. My issue
was because even though the Win2k8 server had %SYSTEMROOT%\system32 as
part of the path, no programs could "see" anything in
C:\Windows\system32. The installer heavily uses icacls.exe during the
init routine. Since my path was screwed up, the installer bombed out.
Once I explicitly added C:\Windows\system32 to the SYSTEM's Path
environment variable and re-ran the installer as an admin, everything
worked fine.
Credits to the user.
Go to services.msc
Search for postgres service
Go to Log On tab
Select local account
Profit
The alternative solution for problems with PostgreSQL installer is setting this up with a Docker.
Install Docker Desktop
https://www.docker.com/products/docker-desktop/
Start installed Docker Desktop
In PowerShell, run:
docker pull postgres
In PowerShell, run:
docker run -d -p 5432:5432 --name postgres -e POSTGRES_PASSWORD=mypassword postgres
Now you can connect to the Postgres server for example with pgAdmin on the same machine, using:
host: localhost
port: 5432
maintenance database: postgres
username: postgres
password: mypassword
I think this would be better as individual comments above, but I don't have the required rep. I just spent days on this, with Postgres 10 on Win 10 Creators. My "answer" was to let Postgres put the data in its default install folder instead of my User folder (where it would be automatically backed-up).
1. This problem can happen with no reported install errors at all. On my very first try, I saw:
Failed to load SQL modules into the database cluster.
But that seemed to be due to:
Executing C:\Users\loren\AppData\Local\Temp\postgresql_installer_aee8e5a76f\vcredist_x64.exe /passive /norestart
Script exit code: 3010
MSI (s) (AC:FC) [14:21:35:341]: Product: Microsoft Visual C++ 2013 x86 Minimum Runtime - 12.0.40660.
Restart required. The installation or update for the product required a restart for all changes to take effect.
The restart was deferred to a later time.
Restarting Windows after the failure of the rest of the Postgres installation did not let Postgres run.
Once VC was in place, uninstalling and re-installing Postgres (still with its data in my User folder) completed with no reported errors. But every attempt to access it, by any means, still resulted in something like this:
C:\Program Files\PostgreSQL\10\bin>psql
psql: could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
The RawCap sniffer showed TCP SYN followed immediately by RST,ACK on localhost for both v4 and v6 for each try. Netstat did not see port 5432 in use at all. All Postgres runtime logs were totally empty. In Windows Services, I could manually start the postgresql-x64-10 service, but it immediately stopped itself, with the note that some services do that normally.
2. I tried moving the data directory via the Postgres wiki procedure. Apparently for Postgres 10 it is incomplete. It does not deal with:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-10\Data Directory
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Services\postgresql-x64-10\Data Directory
C:\Program Files\PostgreSQL\10\pg_env.bat
C:\Program Files\PostgreSQL\10\scripts\serverctl.vbs
But fixing every data file instance I could find did not let it run. And even after fixing all those, and uninstalling and re-installing again with the default location, the new pgAdmin4 somehow still remembered my original User data directory location!
3. I did not try giving NETWORK SERVICE read/write permissions on my User folder. Once the default install worked I wanted to get on with my original project... Maybe that would have worked.
This is a problem using stats(), or just when calculating the database size. Using postgresql in windows 7, localhost.
The problem after doing this is:
"could not stat file "base/17436/119145": Permission denied"
I spent a lot of time trying to fix this problem, until i realise what is really the problem about.
So i'm going to answer myself.
This could be for 2 reasons:
-User of database (login role) without enough permissions.
In this case, check if the user, for example "postgres", have all the controls and privileges active.
-If localhost, check your antivirus, Twice.
Statistics made by postgresql might be considered as a virus movement by many antiviruses (ESET in my case), is a false positive, the only solution is to locate the directory of the database (like \PostgreSQL\9.3\data) and create am exception to that directory in your antivirus software.
As you can see, this second option is not related to the database code it self.
Hope this help you.
In my case (as #JB suggested) restarting the PostgreSQL service will work in some instances.
in my case I got this error after broke an "reindexdb.exe database" command with Ctrl-C. I was running it on Windows 7 command prompt.
Stop-Start of the PostgreSQL service solved the problem.
i got a problem with mongo on a ubuntu server precise 12.04, after apt-get install mongodb-10gen, when i try "mongo", got this error :
terminate called after throwing an instance of 'boost::filesystem3::filesystem_error'
what(): boost::filesystem::status: Permission denied: "/sys/devices/system/node/node1"
Aborted
I tried to look "/sys/devices/system/node/node1" permissions but it seems not to exist.
Anyone got an idea?
Did you install on a OVH server?
I had the same issue today, and it turned out to be a kernel issue (I chose a "approved by OVH kernel"). Installing a stock Ubuntu kernel solved the issue.
I had the same issue on an OVH server, but I didn't want to reinstall with another kernel...
My workaround was to create a group "sysfs" and add "mongodb" user to this group.
Then I did several "chgrp sysfs ..." and "chmod g+rx ..." so that sysfs group can have read access to the directories needed by mongodb:
/sys/devices/system/node
/sys/dev/block/
/sys/devices/virtual/block/md1/queue
Indeed /sys/devices/system/node/node1 doesn't exist, but read access on /sys/devices/system/node was enough.
Note the "mongo" client has the same restriction, so all the users who need it must be added to "sysfs" group as well.
I had the same issue with an OVH debian and solved the problem in a surprisingly simple way: chmod 755 on /sys/devices/system/node/node1 and parent directories.
Same issue with OVH/kimsufi.
I installed default kernel and everything works at least at the time of writing, albeit system became noticeably slower and less responsive.
You will need
Install new kernell
Make in bootable. I was banging my head against the wall for couple of hours before I've realized I haven't made new kernel bootable.
First, make a backup copy of /etc/default/grub and then follow on the guides, for example https://askubuntu.com/questions/156700/how-to-set-default-boot-kernel-in-ubuntu-grub or https://askubuntu.com/questions/309874/how-to-install-linux-kernel-3-9-in-ubuntu or https://askubuntu.com/questions/100232/how-do-i-change-the-grub-boot-order
Here's the corresponding bug report in mongodb: https://jira.mongodb.org/browse/SERVER-10623
It notes that this has been fixed in 2.5.3