What is version number supposed to represent in this CLI command: pg_ctl -D /usr/local/var/postgres[VERSION NUMBER HERE] start ?
VERSION NUMBER HERE usually refers to the major version number (not patch/minor release).
So if you have version 10.3 installed, it should refer to 10
Note that in 9.6 and earlier, major versions had two digits, followed by a patch version (example: 9.5.4 -- major version is 9.5, minor version is 4).
However, what's more important than the version is what folder exists at /usr/local/var -- You could have a data directory that has no versions (i.e., you can do initdb /tmp/foo and all your data will go into foo, and pg_ctl -D /tmp/foo start should get your database started). A good rule of thumb (though there are situations where this fails) is to look for the directory containing postgresql.conf, and that directory is what you would pass as an argument to pg_ctl -D <dir> start
Disclosure: I am an EnterpriseDB (EDB) employee
By including the version number of the Postgres version in the name of the data directory allows you to have multiple clusters (=instances) running at the same time using the same binaries.
Including the version number in the name of the data directory is not mandatory though, and whether it was done during installation or not depends on which Linux distribution you are using. Every distribution does this slightly differently.
But typically you don't start Postgres through pg_ctl but through the systems "service manager", e.g. systemctl or service depending on the Linux distribution. You can check the service definition where the exact location of the data directory is.
Related
I would like to switch from postgres 9.6 to version 14 which runs on Ubuntu 21.04. I have a cluster with 3 databases.
I would like to know what is the difference between upgrading with pg_upgrade and pg_upgradecluster? Which one is faster and safer?
pg_upgrade is a tool from Postgresql itself that will operate on a single database (folder).
pg_upgradecluster however is a wrapper from your operating system (= Ubuntu) to pg_upgrade or pg_dump/pg_restore. In addition to very conveniently upgrading your database, it will also do some housekeeping like moving the config files to the correct folder in /etc/postgres/ .
So, if you have set up your database by pg_createcluster and it is hence listed by pg_lsclusters, I'd strongly recommend using pg_upgradecluster to upgrade it.
In terms of "faster vs. safer", be sure to read about the various options on the manpage.
If you can take a reliable backup (e.g. snapshot), you can safely use the -m upgrade --link option which will be fastest and allow for a very short downtime (depending on database size and resources, but I've recently upgraded a 700GB database in ~25 seconds).
The safest option of course is not using pg_upgrade, but the default pg_dump/pg_restore method, which will shut down your original database and copy the data to a new database in a new location (= it will use at approx. twice the space, at least temporarily until you decide to delete the original folder).
I'm working on creating a Database Cluster (single database) in PostgreSQL 9.x working on a Linux system (CentOS - RedHat - Fedora). I've installed the correct PostgreSQL packages (server & client) however, I'm unable to create a database and get some type of initializing dependencies error: Bus Error / Exit Code 135. I've changed my user to "postgres" with "su postgres" and then tried to initialize the database with "initdb" (this may be the problem)
Installed: postgresql-libs-9.2.13-1.el7_1.x86_64
Installed: postgresql-9.2.13-1.el7_1.x86_64
Installed: postgresql-server-9.2.13-1.el7_1.x86_64
$ initdb -D /usr/local/pgsql/data
http://www.postgresql.org/docs/9.2/interactive/creating-cluster.html
Error:
$ initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
creating directory /usr/local/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 32MB
creating configuration files ... ok
creating template1 database in /usr/local/pgsql/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... sh: line 1: 12616 Bus error (core dumped) "/usr/bin/postgres" --single -F -O -c search_path=pg_catalog -c exit_on_error=true template1 > /dev/null
child process exited with exit code 135
Any ideas?
After installing PostgreSQL (server and client tools) one needs to run the following commands as ROOT ("su"). The key step is to start "service postgresql initdb" and let it initialize your PostgreSQL database.
If you have any errors you need to remove the empty install "data" directories and read all log files carefully.
# service postgresql initdb
# systemctl enable postgresql
# systemctl start postgresql
After doing the above verify that postgres is in /var/lib/pgsql and a running process with "ps -ef | grep postgres" (its on port 5432)
If you run into any other problems you may need to create or modify a postgres user/password or clean a postgres data directory out.
If you installed from packages, you should use the package's provided methods for creating the DB. For the PDGD RPMs (from http://yum.postgresql.org/) that's documented in the README.rpm-dist:
/usr/pgsql-9.4/bin/postgresql94-setup initdb
However, the error you're getting really shouldn't happen. It suggests a hardware incompatibility or a low level issue like an incompatible C library. Perhaps you force-installed RPMs from a different OS or version?
Update:
Seems very likely to be a C library incompatibility. Perhaps an issue between RHEL and CentOS? Or version related? That's a fault in the dynamic linker. dl-lookup.c will be glibc/elf/dl-lookup.c and it seems to be crashing during symbol lookup. So there's something really wonky here, like a corrupt symbol hash table in the binary or an incompatibility between the binary and the dynamic linker used. Or a memory fault, disk fault, CPU cache issue, or other hardware error.
If rebooting makes it go away I'd be very suspicious of the hardware. If it doesn't, you might have something really wonky on the system like some 3rd party unpackaged installer overwriting the original C library / dynamic linker, that sort of weirdness.
I need, as a one-off, to copy data from one table in a PostgreSQL database to the corresponding table in a different database. There's not that much data: about 2500 rows, 8 columns (some numeric, some varchar).
My first thought was to simply pg_dump -a -t table -f output.file and then pg_restore on another database. However, as it turned out, the versions of pg_dump and the source server do not match - and I have no control over versions, so upgrading is not an option:
pg_dump: server version: 9.1.2; pg_dump version: 9.0.5
pg_dump: aborting because of server version mismatch
Unfortunately, with version 9 of Postgres, option -i (ignore version) is not longer available. I do know what I am doing, but it still wouldn't let me (naturally).
What other options do I have?
I would use COPY TO and COPY FROM. Works in either of the versions and is the optimal tool for this.
If you want to use pg_dump, you have to use the appropriate version. There are separate executables for each version. On Linux you can get the path of the currently used executable with which pg_dump.
I was working with postgresql, and suddenly, this stop it. I stoped service, but when i try start it, never i can do it.
service postgresql start FAIL
don't have a backup, and with pg_dump is imposible.
pg_dump -i -h localhost -p 5432 -U postgres -F c -b -v -f "/mibase.backup" mydatabase
which is the best form to do a backup?
I had a lot of trouble with PostgreSQL 9.0.2 under Windows. The service would just stop every couple of days. I never had trouble restarting it, though. Never had to restart the Windows server to restart the PostgreSQL service.
With the PostgreSQL service shut down, you can copy the database files.
If you're not on the most current release of your version, you might try installing a more recent minor version. Postgresql doesn't mind running multiple versions on the same server, although they each have to listen on a different port.
The minor version number is the third digit. Above, the major version is "9.0". If you're running 9.0.2, you want 9.0.[a number greater than 2]. Why?
"Minor releases never change the internal storage format and are always compatible with earlier and later minor releases of the same major version number, e.g., 8.4.2 is compatible with 8.4, 8.4.1 and 8.4.6." (Upgrading a PostgreSQL Cluster)
So a minor version upgrade, listening on a different port, and pointing to your old data directory might let you make a SQL dump. A SQL dump can be restored to any version.
A minor version upgrade pointing to a new data directory should be able to read files copied at the filesystem level. (Paragraph 2, way above.)
I have a (production) DB server running PostgreSQL v9.0 and a development machine running PostgreSQL v8.4. I would like to take a dump of the production DB and use it on the development machine. I cannot upgrade the postgres on the dev machine.
On the production machine, I run:
pg_dump -f nvdls.db -F p -U nvdladmin nvdlstats
On the development machine, I run:
pg_restore -d nvdlstats -U nvdladmin nvdls.db
And I got this error:
pg_restore: [archiver] unsupported version (1.12) in file header
This occurs regardless of whether I choose the custom, tar, or plain_text format when dumping.
I found one discussion online which suggests that I should use a newer version of pg_restore on the dev machine. I tried this by simply copying the 9.0 binary to the dev machine, but this fails (not unexpectedly) due to linking problems.
I thought that the point of using a plain_text dump was that it would be raw, portable SQL. Apparently not.
How can I get the 9.0 DB into my 8.4 install?
pg_restore is only for restoring dumps taken in the "custom" format.
If you do a "plain text" dump you have to use psql to run the generated SQL script:
psql -f nvdls.db dbname username
Using pg_dump/pg_restore to move from 9.0 to 8.4 is not supported - only moving forward is supported.
However, you can usually get the data across (in a data-only dump), and in some cases you can get the schema - but that's mostly luck, it depends on which features you're using.
You should normally use the target version of pg_dump and pg_restore - meaning in this case you should use the binaries from 8.4. But you should use the same version of pg_dump and pg_restore. Both tools will work fine across the network, so there should be no need to copy the binaries around.
And as a_horse_with_no_name says, you may be better off using pg_dump in plaintext mode - that will allow you to hand-edit the dump if necessary. In particular, you can make one schema only dump (with -s) and one data only dump - only the schema dump is likely to require any editing.
If the 9.0 database contains any bytea columns, then bigger problems await.
These columns will be exported by pg_dump using the "hex" representation and appear in your dump file like:
SELECT pg_catalog.lowrite(0, '\x0a2')
Any version of the postgres backend below 9.0 can't grok the hex representation of bytea, and I can't find an option to tell pg_dump on the 9.0 side to not use it. Setting the default "bytea_output" setting to ESCAPE for either the database or the whole server is seemingly ignored by pg_dump.
I suppose it would be possible to post-process the dump file and actually change every hex-encoded bytea value to an escaped one, but the risk of untraceably corrupting the kind of things normally stored in a bytea (images, PDFs etc) does not excite me.
I solved this by upgrading postgresql from 8.X to 9.2.4. If you're using brew on Mac OS-X, use -
brew upgrade postgresql
Once this is done, just make sure your new postgres installation is at the top of your path. It'll look something like (depending on the version installation path) -
export PATH=/usr/local/Cellar/postgresql/9.2.4/bin:$PATH
I had same issue. I used pgdump and psql for export/import DB.
1.Set PGPASSWORD
export PGPASSWORD='h0ld1tn0w';
2.Export DB with pg_dump
pg_dump -h <<host>> -U <<username>> <<dbname>> > /opt/db.out
/opt/db.out is dump path. You can specify of your own.
3.Then set again PGPASSWORD of you another host. If host is same or password is same then this is not required.
4.Import db at your another host
psql -h <<host>> -U <<username>> -d <<dbname>> -f /opt/db.out
If username is different then find and replace with your local username in db.out file. And make sure on username is replaced and not data.