I have a production machine running debian strecth that I do not want to mess up. I have an app that requires postgres 11 and I'm not sure about a thing. Does the installation from the official postgres debian repo install as an extra server or does it replace the existing 9.6 verssion on debian?
I have tried to dump from version 11 and restore in 9.6 but it throws an error on creation of a sequence:
psql:fas-schema.sql:125: ERROR: syntax error at or near "AS"
LINE 2: AS integer
Just need to be sure 100%
If you want to run multiple versions of PostgreSQL one the same host, you should use official packages provided by PGDG. All the currently supported versions are available.
Though, these packages are not including tools provided by the Debian project, such as pg_ctlcluster or pg_lsclusters.
Related
I'm building a pipeline on Azure DevOps with a Linux image as a base (ubuntu-latest). Here I'm installing PostgreSQL version 12 with PostGIS.
Here's what I install:
sudo apt-get install -y postgresql-12 postgresql-client-12 postgresql-12-postgis-3 postgresql-12-postgis-3-scripts
First I tried to install it without mentioning any version numbers, but then I got the error mentioned below and I followed recommendations to specifically do it like this.
Hence the specifically mentioned version numbers
No special additions, just a plain installation of Postgres.
Installation is going fine without any errors.
Then when I create my database and connect to it, I do CREATE EXTENSION POSTGIS; and I get this error:
psql:./create_tables.sql:3: ERROR: could not open extension control file "/usr/share/postgresql/14/extension/postgis.control": No such file or directory
I'm pulling my hair for some time now about this and I totally don't get where it gets that reference to a version 14 folder from. There is absolutely no version 14 installed.
I also tried to pull the Debian packages from the Postgres.org instead of the Ubuntu libraries, I tried to install PostGIS 2.5 and PostGIS 2.5 scripts packages. But whatever I do, I get the same result. Once I start the pipeline, the image gets built and Postgresql and PostGIS installed and then I get the same error as a result.
Did anyone have this same experience? Where could this library folder reference for version 14 come from?
EDIT 2022/05/21: I've added some checks to the scripts and when checking the version of PostgreSQL(via SELECT version(); ) it gives version 14 (!), which at least explains the error. Apparently version 14 indeed IS installed and runs on the default port 5432. Version 12 that is explicitly installed also runs, it runs on port 5433 (checked via cat /etc/postgresql/12/main/postgresql.conf ). I now explicitly start version 12 and connect in my scripts to port 5433, so I can continue, but I still wonder where that version 14 installation comes from.
Postgres 14 is pre-installed on the Microsoft Hosted agent for ubuntu-20
Reference:
https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-Readme.md#postgresql
I try to install pgAdmin3 for postgresql 9.4 but have an error:
Could not find your PostgreSQL installation. You might need to use the
--with-pgsql=DIR configure option.
I saw some questions in this resource, for example
Building pgadmin3-1.20.0 in CentOS 7 with PostgreSQL-9.4
But I've postgresql running in Docker and have not locally installation.
Any ideas how to compile pgAdmin without postgresql installation?
I tried installing postgresql in my server which has centos
I followed this link
I am facing few complexity here.
I could not locate postgresql file in /etc directory.
psql (8.4.13, server 9.2.4) WARNING: psql version 8.4, server version 9.2. Some psql features might not work.
How can i solve these issues. can anyone suggest me.
I could not locate postgresql file in /etc directory.
The tutorial you linked to suggests the config files are in /var/lib/pgsql/9.2/data/...
psql (8.4.13, server 9.2.4) WARNING: psql version 8.4, server version 9.2. Some psql features might not work.
You've still got the 8.4 version of psql installed. Use your package tools (rpm/yum) to see what versions of the psql client packages are installed and where the binaries are.
It's common enough to run two different versions of PG on the same machine. Obviously each needs its own data directory and port number. Also, as you've seen psql will check the version number and warn if they are different. Basic queries still work, but obviously an 8.4 version won't know about extensions introduced in 9.1 and that sort of thing.
When trying to get local data to Heroku, I am encountering a version mismatch between two different versions of pg_dump.
Specifically, I am getting this message:
pg_dump: server version: 9.2.2; pg_dump version: 9.1.4
pg_dump: aborting because of server version mismatch
I have found others with this problem, but do not know enough to implement the proposed solutions. (I am new to Ruby on Rails, PostgreSQL, Heroku, and the Mac! Very much at the stage of playing around the picking things up as I go.)
I was thinking I might simplify my life if I uninstalled all PostgreSQL on my local machine and started again with a clean install of PostgreSQL 9.2.2 from http://postgresapp.com/, but I don't know how to go about doing the uninstall.
I'm running Mac OS X Mountain Lion 10.8.2.
OS X 10.8 comes with pg_dump version 9.1.4 in the /usr/bin directory, along with psql and other programs that are client-side PostgreSQL tools. It does not mean that PostgreSQL as a server is installed (unless you have OS X Server Edition).
So you don't have to uninstall PostgreSQL because it's not installed and it's better not to remove these postgres client tools in /usr/bin because they belong to the system as shipped by Apple. They just need to be side-stepped.
The package provided by postgres.app comprises both the PostgreSQL server and the client-side tools of the same version as this server. These tools get installed in /Applications/Postgres.app/Contents/MacOS/bin
To use these instead of the 9.1 ones from Apple when you work in a Terminal, postgres.app documentation says to do:
PATH="/Applications/Postgres.app/Contents/MacOS/bin:$PATH"
and put it in your .profile file.
Once you have done that and you run pg_dump, you should no longer get the error that's it's the wrong version, because it would be the one that ships with postgres.app (currently 9.2.2).
I have this setup and it works OK for me.
If you only need to upgrade your pg_dump to the latest version and you have homebrew and mac, if the app has the latest version and your local pg doesn't:
brew upgrade postgresql
If you're using postgresapp 9.3.x, the path is different. The following worked for me (courtesy of http://sigmyers.com/blog/2013/3/12/postgres-pgdump-version-mismatch-error-postgresapp-postgresappcom)
export PG_BIN_PATH="/Applications/Postgres.app/Contents/Versions/9.3/bin/"
PATH=$PG_BIN_PATH:$PATH
Check here for the latest path: http://postgresapp.com/documentation/cli-tools.html
I'm running Mountain Lion Server. My PostgeSQL server is at version 9.2.1 and the default tools are at 9.1.5.
I had to use:
PATH="/Applications/Server.app/Contents/ServerRoot/usr/bin:$PATH"
to make it work.
Yep, sometimes if you run Postgres.app this may happen after upgrade. Make sure you restart your Postgres.app - it will update your PATH.
In my case I have postgresql installed via homebrew and the executables are here: /usr/local/opt/postgresql#9.6/bin
Or you copy the dump and restore executions to the /Applications/Postgres.app/Contents/SharedSupport folder
or in PdAgmin you point the PG bin Path (in properties -> binary Path) to the path of the executables of your postgre
I upgraded my Ubuntu 8.04 To Ubuntu 10.04. Unfortunately, the upgrade process also updated the Postgres 8.3 install to a Postgres 8.4 install. My feeling is that although database engine binaries have been updated, the database itself was not migrated, hence it can not be loaded by the 8.4.
Since the 8.3 data format is not compatible with 8.4 format, altering postgresql.conf is not enough, nor can I use pg_dump with my 8.4 install.
I need a way to upgrade my previous base from 8.3 to 8.4, with no access to a 8.3 engine, only a 8.4.
Any clue?
The postgres packages in Debian, and hence, Ubuntu, has a very clearly defined way of upgrading from one Postgres version to another. The procedure is documented in /usr/share/doc/postgresql-common/README.Debian as follows:
Default clusters and upgrading
------------------------------
When installing a postgresql-X.Y package from scratch, a default
cluster 'main' will automatically be created. This operation is
equivalent to doing 'pg_createcluster X.Y main --start'.
Due to this default cluster, an immediate attempt to upgrade an
earlier 'main' cluster to a new version will fail and you need to
remove the newer default cluster first. E. g., if you have
postgresql-8.2 installed and want to upgrade to 8.3, you first install
postgresql-8.3:
apt-get install postgresql-8.3
Then drop the default 8.3 cluster:
pg_dropcluster 8.3 main --stop
And then upgrade the 8.2 cluster to 8.3:
pg_upgradecluster 8.2 main
The best time to do this is before ugrading to a version of Ubuntu where the version of Postgresql you're currently running has been removed, i.e. in this example, while on a version of Ubuntu that has the possibility to install both Postgres 8.3 and Postgres 8.4. In my case, I went from jaunty to karmic, upgraded 8.3 to 8.4 and then went from karmic to lucid.
The upgrade process as described above is very smooth. The *pg_upgradecluster* command will stop the old version, migrate data, then start the new version on the same port as the old version, finally starting the old version on a new port.
If you did not migrate your 8.3 postgres data before moving to an Ubuntu version that lacks postgres 8.3, migrating is still simple. Start by adding the karmic ubuntu repository to /etc/apt/sources.list:
deb http://archive.ubuntu.com/ubuntu/ karmic main restricted universe
Install postgresql-8.3:
apt-get update && apt-get install postgresql-8.3
Drop your 8.4 cluster. Warning: This will remove data in your postgresql 8.4 installation if you have any. But if you're only doing this because you need to upgrade your 8.3 to 8.4, you will have no data in your 8.4 cluster.
pg_dropcluster 8.4 main --stop
And then upgrade the 8.3 cluster to 8.4:
pg_upgradecluster 8.3 main
Finally, remove the postgresql-8.3 package, and remove the jaunty-line from /etc/apt/sources.list, then run apt-get update again.
As usual, taking a backup of your postgres directories before doing any of the above is always a good idea.
You'll have to install PostgreSQL 8.3 in temporary location from source, copy your old data there, start Pg, dump it's data using pd_dumpall and then import this data to new Postgres.
It's impossible without installing Pg 8.3.
Make sure you backup everything before you try anything.
There is the pg_migrator project which I think will do that for you, though I'm not sure whether it needs to 8.3 applications or source code.