So this morning I couldn't install Postgres 9.1 from the Ubuntu repo. I tried installing 9.2 from postgres repo, but if failed with the same error. The error trace is really uninformative (I don't even know what is the source of this error). Google didn't tell me anything as well.
It failed during installation with the same error, and I tried to create the cluster manually. But...
root#Ubuntu-1304-raring-64-minimal /home/tmp # pg_createcluster 9.2 main --start
Creating new cluster (configuration: /etc/postgresql/9.2/main, data: /var/lib/postgresql/9.2/main)...
FATAL: syntax error at line 5067: unexpected character ";"
child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/postgresql/9.2/main"
Error: initdb failed
What is wrong?
According to this output from dpkg -l 'postgres*':
ii postgresql-9.2 9.2.4-1.pgdg12.4+1 amd64 object-relational SQL database, version 9.2 server
un postgresql-client (no description available)
ii postgresql-client-9.1 9.1.9-1ubuntu1 amd64 front-end programs for PostgreSQL 9.1
ii postgresql-client-9.2 9.2.4-1.pgdg12.4+1 amd64 front-end programs for PostgreSQL 9.2
ii postgresql-client-common 140 all manager for multiple PostgreSQL client versions
ii postgresql-common 140 all
postgresql-9.2 is already installed (see the ii flags in the leftmost column), as well as the client tools for 9.1 and 9.2 from a mix of pgdg and ubuntu repositories.
Anyway, the error encountered by pg_createcluster is quite unusual. From the output, especially the line number, it would seem that the underlying initdb fails when playing the postgres.bki file.
For 9.2, this file is: /usr/share/postgresql/9.2/postgres.bki. It contains low-level commands in a sql-like dialect to populate the cluster with pre-initialized data (template databases, pre-defined types and views, etc.)
It's hard to imagine that this file would be corrupted, especially since you have a similar problem when installing 9.1 that comes with a different postgres.bki file right from the package.
Still you may check just in case what's at line 5067 and around. In my build directory for 9.2.4, I have this:
insert OID = 1 ( template1 10 ENCODING "LC_COLLATE" "LC_CTYPE" t t -1 0 0 1663 _null_)
And there isn't a ; character anywhere in the entire file.
Other than that, you may want to remove the entire postgresql installation to restart from a clean base:
# purge client packages
dpkg --purge postgresql-client-9.1 postgresql-client-9.2 postgresql-client-common
# purge server packages
dpkg --purge postgresql-9.2 postgresql-common
You're... trying to install postgres?
Either one of these commands should get you on your way:
sudo apt-get install postgresql-9.1
sudo apt-get install postgresql-9.2
Here's the download page
If those commands returned an error, the error response would be helpful information to include in your question.
I'm afraid I've never tried manually creating the clusters before, so I'm probably not of much help.
Related
I installed psql on my system without having added any new package sources. Later,I added postgres's package repo following the instructions on their website and ran sudo apt install postgres. I then ran sudo apt remove postgres.
Now, when I run sudo apt remove postgresql again, apt tells me "Unable to locate package postgresql". However, running dpkg -l | grep sql yields (among other things):
ii postgresql-14 14.5-0ubuntu0.22.04.1 amd64 The World's Most Advanced Open Source Relational Database
ii postgresql-15 15.1-1.pgdg22.04+1 amd64 The World's Most Advanced Open Source Relational Database
ii postgresql-client-14 14.5-0ubuntu0.22.04.1 amd64 front-end programs for PostgreSQL 14
ii postgresql-client-15 15.1-1.pgdg22.04+1 amd64 front-end programs for PostgreSQL 15
ii postgresql-client-common 246.pgdg22.04+1 all manager for multiple PostgreSQL client versions
ii postgresql-common 246.pgdg22.04+1 all PostgreSQL database-cluster manager
And running psql --version from the command line yields psql (PostgreSQL) 15.1 (Ubuntu 15.1-1.pgdg22.04+1).
Here are some questions, info about any is appreciated:
Why can't apt find the postgresql package even though psql is installed?
What package is psql part of and how do I figure that out? Does psql still exist on my system because it is part of a package that another package I have installed depends on?
I'm just interested in using the most recent LTS version of postgres (15.1 at the time I'm writing this). Do I need the version 14 packages which exist on my systems? If not, how do I remove them?
Edit: After sudo apt removeing postgresql-14 and postgresql-15, psql still exists on my system but gives the following error: psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory. Why does the psql command still work?
I've followed the official installation instructions for my Centos 7 machine:
# Install the repository RPM:
sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
# Install PostgreSQL:
sudo yum install -y postgresql13-server
# Optionally initialize the database and enable automatic start:
sudo /usr/pgsql-13/bin/postgresql-13-setup initdb
sudo systemctl enable postgresql-13
sudo systemctl start postgresql-13
The issue comes at the initdb stage. Instead of getting the typical "OK" at the end of execution, I'm given nothing. After looking through the postgresql-13-setup script, I managed to find an ouput log at /var/lib/pgsql/13/initdb.log:
/usr/pgsql-13/bin/initdb: error while loading shared libraries: libpq.so.5: cannot open shared object file: No such file or directory
It looks like, for whatever reason, libpq.so.5 (which is present in other past postgres installs) is missing from /usr/pgsql-13/lib/.
I've tried uninstalling/reinstalling postgres-13 multiple times now, clearing out the service, deleting all the directories, etc. This issue is only happening in this specific machine (I've installed postgres 13 in various other similar machines with no issue).
edit:
Ad requested, running:
/usr/pgsql-13/bin/initdb -E UTF8 /var/lib/pgsql/13/data
Returns the same exact error:
/usr/pgsql-13/bin/initdb: error while loading shared libraries: libpq.so.5: cannot open shared object file: No such file or directory
I am getting an error after moving the project to production. The error is as follows while running with production server
pg_connect(): Unable to connect to PostgreSQL server: SCRAM
authentication requires libpq version 10 or above.
Here is my PostgreSQL version:
Development Version :
PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623
(Red Hat 4.8.5-36), 64-bit
Production Version :
PostgreSQL 11.5 (EnterpriseDB Advanced Server 11.5.12) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
For those on M1-Based macs who are currently seeing this issue in docker - there appears to a bug upstream in libpg that's building against the wrong library version on ARM.
Until it's fixed, a workaround is to (at a performance hit) is to just run it via rosetta.
export DOCKER_DEFAULT_PLATFORM=linux/amd64, and re-build your images.
You'll get the latest version of libpq, and things should Just Work.
Ref: https://github.com/psycopg/psycopg2/issues/1360
Your application uses an API that is linked with the PostgreSQL client C library libpq.
The version of that library must be 9.6 or older, and SCRAM authentication was introduced in v10.
Upgrade libpq on the application end and try again.
If you don't need scram-sha-256 authentication, you can revert to md5:
set password_encryption = md5 in postgresql.conf
change the authentication method to md5 in pg_hba.conf
reload PostgreSQL
change the password of the user to get an MD5 encrypted password
I ran into this while running a python:3.9 docker image where I had installed psycopg2-binary==2.9.3. Installing psycopg2==2.9.3 instead resolved it for me.
For Amazone linux users:
$ sudo yum install -y amazon-linux-extras
then re install the postgres client again
$ sudo amazon-linux-extras install postgresql10
Then the main part install the python package in my case it was (psycopg2) reinstall it
$ pip3 install --force-reinstall psycopg2==2.93
specification:
python3.8.9
I used to get an error SCRAM authentication requires libpq version 10 or above when running php artisan migrate in laravel 8. Then I fixed it as follows: Change authentication from scram-sha-256 to md5, then reset your password and restart the postgresql-x64-13 service and here are step by step:
Step 1: Find file postgresql.conf in C:\Program Files\PostgreSQL\13\data then set password_encryption = md5
Step 2: Find file pg_hba.conf in C:\Program Files\PostgreSQL\13\data then change all METHOD to md5
Step 3: Open command line (cmd,cmder,git bash...) and run psql -U postgres then enter your password when installed postgres sql
Step 4: Then change your password by run ALTER USER postgres WITH PASSWORD 'new-password' in command line
Final: Restart service postgresql-x64-13 in your Service.
If you want to keep the scram-sha-256 for security. You need to update your client postgreSQL libraries, due to php-pgsql default version does not support it.
CentOS/Rhel/Rocky
yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
yum install postgresql13
This will update the server/client libpq in order to keep using scram-sha-256
This issue still affects m1 macs running python:3.10.* docker containers (based off aarch64 Debian 11). Solution for me was to install psycopg2 (build from source) instead of psycopg2-binary which is advised for production anyways:
pip install psycopg2
The python container has all the build dependencies already (like gcc). A more production appropriate container most likely won't have these https://www.psycopg.org/docs/install.html#build-prerequisites
I find 2 solutions. I didn't try local, solutions are for docker container.
Preliminary information:
According to the main image we defined at the beginning of the Dockerfile, our libq versions may differ. It is explained with examples in the answer given here.
If you want to know your libq version used in your docker-image, you can do the following, respectively.
After docker-compose run
docker-compose exec <app_name_in_docker-compose_file> sh
python
import psycopg2
print(psycopg2.extensions.libpq_version())
If you're getting an error, you'll probably see a number like 90xxx here.
Solutions:
First basic one. I used 'python:3.9-slim-buster' at docker and I've got error. Change base image name to 'python:3.9.6-alpine3.14'
The second solution is to build the psycopg2 file and install libq and other dependencies. For this, add the following commands to the dockerfile.
RUN apt update -y && apt install -y build-essential libpq-dev
RUN pip3 install psycopg2-binary --no-binary psycopg2-binary
All the answers that are suggesting that password encryption should be reverted back to md5 are forgetting that PostgreSQL changed its default password encryption from md5 to scram-sha-256 for security reasons.
The issue then is those client applications that fail to use this modern encryption method. The libpq file that ships with PostgreSQL version 10 and above is fine. Just change your client applications if you can so that you use only the ones that support this new method.
For instance, For a long time I was using a package called RPostgreSQL that allows users to connect to a PostgreSQL database from R. Turns out that package doesn't support scram-sha-256. I have now replaced it with its modern equivalent called rpostgres. Problem solved, everybody happy now!
Based on answer by #meijsermans, I changed the requirements.txt for django:
#psycopg2-binary>=2.9.3
psycopg2>=2.9.5
and it worked without the SCRAM error!
Also tried with and without platform: linux/arm64 in docker.compose, didn't solve the problem.
Tried platform: linux/amd64 and had some unrelated errors (mainly "exec /bin/sh: exec format error")
Using postgres:14.5 image in postgres container and python:3.10.7 image for django
Had this issue and fixed it by switching from the binary version of psycopg2 to psycopg2 = "^2.9.3"
Thanks to previous answers, this was resolved in my case too when I switched from psycopg2-binary to psycopg2.
Use pip install psycopg2 in your environment. This resolves the issue for ubuntu based systems.
Encountered the same issue and applied #Laurenz Albe's fix but I would get an authentication error on my user for the database, because of encryption strategy change.
So instead of replacing scram-sha-256 with md5, replace it with trust in pg_hba.conf
Here is a more mundane answer, but this is what happened to me so I'll add it here.
I got this error when I tried to start PostgreSQL 9.4. I realized I already had PostgreSQL 11 running - it started automatically with my computer. Once I stopped version 11, I was able to start version 9.4. They can't listen on a port already in use, and both had the same port set. But I'm not sure exactly why the misleading error wording.
Found this problem installing on a ubuntu 22.04 image with python3.10 on Mac M1.
What worked for me was installing the psycopg2 package as root rather than with --user - then the specific user can use the package.
Looks like the --user install puts an incorrectly linked libpq at
/home/<user...>/.local/lib/python3.10/site-packages/psycopg2_binary.libs/libpq-d97d8807.so.5.9
If you have another pip install --user process kicking about after this, and it installs psycopg2 again under the .local path, just remove that from .local/lib/python3.x/site-packages/psycopg2*
Use vi (or other editor) to replace scram-sha-256 with md5 in the file postgresql.conf and post_hba.conf ; location of the files depends on your local set up. After this step 1 you may (most likely) continue to have the issue of authentication error. This is bcos the hash of password in DB still uses scram encryption. We will solve in the next few steps.
Restart postgresql server. This command depends on your server setup as well.
Reload DB and verify. Login with postgres id: sudo -u postgres sql
Reload (under the psql console):
SELECT pg_reload_conf();
Check Encryption:
SHOW password_encryption;
SELECT * FROM pg_hba_file_rules();
Reset password for user account (within the psql consol). This step will flush a new hash for the password under md5 to replace the existing scram hash of the user password.
\password user_id
Then you can run a test of DB connection with psycopg2, as well as sqlalchemy.
This solves my problem in the way i can understand, being aware that md5 is less ideal an encryption method than scram-sha-256 but recompile the package to meet the requirement of psycopg2 is a pain in a**. So i would switch back to md5 first then when the package are all ready then change it to scram encryption.
Reference: PostgreSQL downgrade password encryption from SCRAM to md5
RUN apt-get -y update \
&& apt-get install -y build-essential gettext libpq-dev\
&& apt-get install -y wkhtmltopdf\
&& apt-get install -y gdal-bin\
&& apt-get install -y libgdal-dev\
&& apt-get install -y --no-install-recommends software-properties-common\
&& apt-add-repository contrib\
&& apt-get update
Try this.
I am getting an error after moving the project to production. The error is as follows while running with production server
pg_connect(): Unable to connect to PostgreSQL server: SCRAM
authentication requires libpq version 10 or above.
Here is my PostgreSQL version:
Development Version :
PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623
(Red Hat 4.8.5-36), 64-bit
Production Version :
PostgreSQL 11.5 (EnterpriseDB Advanced Server 11.5.12) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
For those on M1-Based macs who are currently seeing this issue in docker - there appears to a bug upstream in libpg that's building against the wrong library version on ARM.
Until it's fixed, a workaround is to (at a performance hit) is to just run it via rosetta.
export DOCKER_DEFAULT_PLATFORM=linux/amd64, and re-build your images.
You'll get the latest version of libpq, and things should Just Work.
Ref: https://github.com/psycopg/psycopg2/issues/1360
Your application uses an API that is linked with the PostgreSQL client C library libpq.
The version of that library must be 9.6 or older, and SCRAM authentication was introduced in v10.
Upgrade libpq on the application end and try again.
If you don't need scram-sha-256 authentication, you can revert to md5:
set password_encryption = md5 in postgresql.conf
change the authentication method to md5 in pg_hba.conf
reload PostgreSQL
change the password of the user to get an MD5 encrypted password
I ran into this while running a python:3.9 docker image where I had installed psycopg2-binary==2.9.3. Installing psycopg2==2.9.3 instead resolved it for me.
For Amazone linux users:
$ sudo yum install -y amazon-linux-extras
then re install the postgres client again
$ sudo amazon-linux-extras install postgresql10
Then the main part install the python package in my case it was (psycopg2) reinstall it
$ pip3 install --force-reinstall psycopg2==2.93
specification:
python3.8.9
I used to get an error SCRAM authentication requires libpq version 10 or above when running php artisan migrate in laravel 8. Then I fixed it as follows: Change authentication from scram-sha-256 to md5, then reset your password and restart the postgresql-x64-13 service and here are step by step:
Step 1: Find file postgresql.conf in C:\Program Files\PostgreSQL\13\data then set password_encryption = md5
Step 2: Find file pg_hba.conf in C:\Program Files\PostgreSQL\13\data then change all METHOD to md5
Step 3: Open command line (cmd,cmder,git bash...) and run psql -U postgres then enter your password when installed postgres sql
Step 4: Then change your password by run ALTER USER postgres WITH PASSWORD 'new-password' in command line
Final: Restart service postgresql-x64-13 in your Service.
If you want to keep the scram-sha-256 for security. You need to update your client postgreSQL libraries, due to php-pgsql default version does not support it.
CentOS/Rhel/Rocky
yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
yum install postgresql13
This will update the server/client libpq in order to keep using scram-sha-256
This issue still affects m1 macs running python:3.10.* docker containers (based off aarch64 Debian 11). Solution for me was to install psycopg2 (build from source) instead of psycopg2-binary which is advised for production anyways:
pip install psycopg2
The python container has all the build dependencies already (like gcc). A more production appropriate container most likely won't have these https://www.psycopg.org/docs/install.html#build-prerequisites
I find 2 solutions. I didn't try local, solutions are for docker container.
Preliminary information:
According to the main image we defined at the beginning of the Dockerfile, our libq versions may differ. It is explained with examples in the answer given here.
If you want to know your libq version used in your docker-image, you can do the following, respectively.
After docker-compose run
docker-compose exec <app_name_in_docker-compose_file> sh
python
import psycopg2
print(psycopg2.extensions.libpq_version())
If you're getting an error, you'll probably see a number like 90xxx here.
Solutions:
First basic one. I used 'python:3.9-slim-buster' at docker and I've got error. Change base image name to 'python:3.9.6-alpine3.14'
The second solution is to build the psycopg2 file and install libq and other dependencies. For this, add the following commands to the dockerfile.
RUN apt update -y && apt install -y build-essential libpq-dev
RUN pip3 install psycopg2-binary --no-binary psycopg2-binary
All the answers that are suggesting that password encryption should be reverted back to md5 are forgetting that PostgreSQL changed its default password encryption from md5 to scram-sha-256 for security reasons.
The issue then is those client applications that fail to use this modern encryption method. The libpq file that ships with PostgreSQL version 10 and above is fine. Just change your client applications if you can so that you use only the ones that support this new method.
For instance, For a long time I was using a package called RPostgreSQL that allows users to connect to a PostgreSQL database from R. Turns out that package doesn't support scram-sha-256. I have now replaced it with its modern equivalent called rpostgres. Problem solved, everybody happy now!
Based on answer by #meijsermans, I changed the requirements.txt for django:
#psycopg2-binary>=2.9.3
psycopg2>=2.9.5
and it worked without the SCRAM error!
Also tried with and without platform: linux/arm64 in docker.compose, didn't solve the problem.
Tried platform: linux/amd64 and had some unrelated errors (mainly "exec /bin/sh: exec format error")
Using postgres:14.5 image in postgres container and python:3.10.7 image for django
Had this issue and fixed it by switching from the binary version of psycopg2 to psycopg2 = "^2.9.3"
Thanks to previous answers, this was resolved in my case too when I switched from psycopg2-binary to psycopg2.
Use pip install psycopg2 in your environment. This resolves the issue for ubuntu based systems.
Encountered the same issue and applied #Laurenz Albe's fix but I would get an authentication error on my user for the database, because of encryption strategy change.
So instead of replacing scram-sha-256 with md5, replace it with trust in pg_hba.conf
Here is a more mundane answer, but this is what happened to me so I'll add it here.
I got this error when I tried to start PostgreSQL 9.4. I realized I already had PostgreSQL 11 running - it started automatically with my computer. Once I stopped version 11, I was able to start version 9.4. They can't listen on a port already in use, and both had the same port set. But I'm not sure exactly why the misleading error wording.
Found this problem installing on a ubuntu 22.04 image with python3.10 on Mac M1.
What worked for me was installing the psycopg2 package as root rather than with --user - then the specific user can use the package.
Looks like the --user install puts an incorrectly linked libpq at
/home/<user...>/.local/lib/python3.10/site-packages/psycopg2_binary.libs/libpq-d97d8807.so.5.9
If you have another pip install --user process kicking about after this, and it installs psycopg2 again under the .local path, just remove that from .local/lib/python3.x/site-packages/psycopg2*
Use vi (or other editor) to replace scram-sha-256 with md5 in the file postgresql.conf and post_hba.conf ; location of the files depends on your local set up. After this step 1 you may (most likely) continue to have the issue of authentication error. This is bcos the hash of password in DB still uses scram encryption. We will solve in the next few steps.
Restart postgresql server. This command depends on your server setup as well.
Reload DB and verify. Login with postgres id: sudo -u postgres sql
Reload (under the psql console):
SELECT pg_reload_conf();
Check Encryption:
SHOW password_encryption;
SELECT * FROM pg_hba_file_rules();
Reset password for user account (within the psql consol). This step will flush a new hash for the password under md5 to replace the existing scram hash of the user password.
\password user_id
Then you can run a test of DB connection with psycopg2, as well as sqlalchemy.
This solves my problem in the way i can understand, being aware that md5 is less ideal an encryption method than scram-sha-256 but recompile the package to meet the requirement of psycopg2 is a pain in a**. So i would switch back to md5 first then when the package are all ready then change it to scram encryption.
Reference: PostgreSQL downgrade password encryption from SCRAM to md5
RUN apt-get -y update \
&& apt-get install -y build-essential gettext libpq-dev\
&& apt-get install -y wkhtmltopdf\
&& apt-get install -y gdal-bin\
&& apt-get install -y libgdal-dev\
&& apt-get install -y --no-install-recommends software-properties-common\
&& apt-add-repository contrib\
&& apt-get update
Try this.
omnia#ubuntu:~$ psql --version
psql (PostgreSQL) 9.3.4
omnia#ubuntu:~$ pg_dump --version
pg_dump (PostgreSQL) 9.2.8
omnia#ubuntu:~$ dpkg -l | grep pg
ii gnupg 1.4.11-3ubuntu2.5 GNU privacy guard - a free PGP replacement
ii gpgv 1.4.11-3ubuntu2.5 GNU privacy guard - signature verification tool
ii libgpg-error0 1.10-2ubuntu1 library for common error values and messages in GnuPG components
ii libpq5 9.3.4-1.pgdg60+1 PostgreSQL C client library
ii pgdg-keyring 2013.2 keyring for apt.postgresql.org
ii postgresql-9.2 9.2.8-1.pgdg60+1 object-relational SQL database, version 9.2 server
ii postgresql-9.3 9.3.4-1.pgdg60+1 object-relational SQL database, version 9.3 server
ii postgresql-client-9.2 9.2.8-1.pgdg60+1 front-end programs for PostgreSQL 9.2
ii postgresql-client-9.3 9.3.4-1.pgdg60+1 front-end programs for PostgreSQL 9.3
ii postgresql-client-common 154.pgdg60+1 manager for multiple PostgreSQL client versions
ii postgresql-common 154.pgdg60+1 PostgreSQL database-cluster manager
ii python-gnupginterface 0.3.2-9.1ubuntu3 Python interface to GnuPG (GPG)
ii unattended-upgrades 0.76ubuntu1 automatic installation of security upgrades
ii update-manager-core 1:0.156.14.13 manage release upgrades
omnia#ubuntu:~$
Seems I have both installed but pg_dump is stuck in an older version? Weird since both are linked to the same "wrapper":
omnia#ubuntu:~$ readlink /usr/bin/psql
../share/postgresql-common/pg_wrapper
omnia#ubuntu:~$ readlink /usr/bin/pg_dump
../share/postgresql-common/pg_wrapper
What am I doing wrong?
sudo rm /usr/bin/pg_dump
sudo ln -s /usr/lib/postgresql/9.3/bin/pg_dump /usr/bin/pg_dump
If your pg_dump is sym-linked to pg_wrapper, then the best fix is to tell pg_wrapper which version to use.
Append
* * 9.6 localhost:5432 *
to /etc/postgresql-common/user_clusters, (assuming your postmaster is listening on localhost:5432 of course).
This then fixes the problem for all pg_ commands, doesn't involve breaking anything, and scales nicely for future versions which you may wish to install.
See man pg_wrapper and man postgresqlrc for details and other options.
NB This answer is specifically for Debian/Ubuntu, and is most likely applicable when there are two version of pg installed, eg. after an upgrade.
The pgdg60 package suffix leads me to believe these packages are not from the official Ubuntu repository. Try looking into /etc/apt/sources.list or /etc/apt/sources.list.d and see if you have any third party PPA's or repositories specified.
Try getting the Postgresql packages either from your Ubuntu repo (although these may be a bit out-of-date depending on your Ubuntu version), or from the official postgres repo (they provide an apt server for Ubuntu/Debian): https://wiki.postgresql.org/wiki/Apt