Running PostgreSQL on MANJARO, the actual /var/lib/postgres/data/postgresql.conf defines my Data-Directory:
data_directory = '/mnt/Data/.../PostgreSQL'
Now I'm facing the upgrade from PostgreSQL 13 to 14 and I'm thinking to use pg_upgrade, as described in the Arch-Wiki.
The Step 4.) described there is pretty clear, but is it also sufficient for my data_directory = '/mnt/Data/.../PostgreSQL' or do I need to take additional actions?
Furthermore, I'm thinking to have versioned directories, e.g.
/var/lib/postgres/data/14/
/mnt/Data/.../PostgreSQL/14/
What should I consider to realize that?
Thank you!
When running pg_upgrade, point the --old-datadir and --new-datadir options to the directories that contain postgresql.conf (not to the actual data directories). I admit that this is confusing; however, the documentation says:
-d configdir
--old-datadir=configdir
the old database cluster configuration directory; environment variable PGDATAOLD
Note that the wording is “cluster configuration directory”, not “data directory”.
Related
I have a Postgresql 10 installation on Ubuntu 18.04 that somehow broke and won't restart. Can I just reinstall it without destroying its databases, so that I can access the databases again? pg_dump doesn't work.
Yes, you can do that.
By default, your databases and other important files are stored in PGDATA.
Traditionally, the configuration and data files used by a database cluster are stored together within the cluster's data directory, commonly referred to as PGDATA (after the name of the environment variable that can be used to define it). A common location for PGDATA is /var/lib/pgsql/data.
https://www.postgresql.org/docs/10/storage-file-layout.html
I don't know how you will uninstall PostgreSQL, but be sure to keep PGDATA.
(yum or apt won't delete PGDATA)
After re-installing PostgreSQL, make sure to launch your PostgreSQL with your existing PGDATA
pg_ctl start -D YOUR_EXISTING_PGDATA/
I am installing postgres 8.4 on an ubuntu lucid server (no, at the moment we are using the "lucid" LTS version on that server so an upgrade is not possible yet (although we are going to start testing the system on precise quite soon now))
I have set up an own partition for the /var/lib/postgresql/8.4/main directory with a ext4 file system. (Those of you who are really into postgres installs knows what is happening now...) Since ext4 puts a lost+found directory in the root of all file system, postgres will not use that directory as its data-directory since it is initially not empty...
initdb: directory "/var/lib/postgresql/8.4/main" exists but is not empty
If you want to create a new database system, either remove or empty
the directory "/var/lib/postgresql/8.4/main" or run initdb
with an argument other than "/var/lib/postgresql/8.4/main".
The easiest way to proceed would be to remove the lost+found and recreate it after initdb has done its job. - could that cause any problems? Does the lost+found have any special attributes or anything that makes it impossible to recreate, and also, it is needed at any other time than if checkdisk finds something it needs to put there?
Another way would be to unmount the .../main/ file system, init the database, temporary mount the .../main/ filesystem somewhere else, move things over there and mount it in place. Seems to be a bit more work than the "easiest way".
Or is it some way to make initdb ignore that the directory is not empty? (couldn't see any command line switches for that)
May a lost+found directory within postgres main directory cause any problems?
At the moment I am running the system on a virtual machine for testing, so it really doesn't matter if I mess up things, but before making this an official way of installing a mission-critical system, it would be nice to have some thoughts on this.
lost+found has preallocated blocks that make it easier for fsck to move data into it when the partition is short of free blocks. To create it, better use the mklost+found command rather than mkdir.
If you don't recreate it, fsck will do it anyway when it's needed.
But if it comes to the point where fsck finds corruption within PGDATA, I'd think about going for a backup rather than counting on lost+found to retrieve anything.
I want to make a script that will run postgres in-memory without durability.
I read this page: http://www.postgresql.org/docs/9.1/static/non-durability.html
But I didn't understand how I can set this parameters in script. Could you please, help me?
Thanks for help!
Most of those parameters, like fsync, can only be set in postgresql.conf. Changes are applied by re-starting PostgreSQL. They apply to the whole database cluster - all the databases in that PostgreSQL install. That's because the databases all share a single postmaster, write-ahead log, and set of shared system tables.
The only parameter listed there that you can set at the SQL level in a script is synchronous_commit. By setting synchronous_commit = 'off' you can say "it's OK to lose this transaction if the database crashes in the next few seconds, just make sure it still applies atomically".
I wrote more on this topic in a previous answer, Optimise PostgreSQL for fast testing.
If you want to set the other params with a script you can do so but you have to do it by opening and modifying postgresql.conf using the script, then re-starting PostgreSQL. Text-processing tools like sed make this kind of job easier.
If you're running a debian based linux distro, you can just do something like:
pg_createcluster -d /dev/shm/mypgcluster 8.4 ramcluster
to create a ram based cluster. Note that you'll have to do:
pg_drop cluster 8.4 ramcluster
and recreate it on reboot etc.
We have the "coverity" tool setup and are trying to find a way to backup the database to a file, it uses I believe PostgreSQL.
How can we do this, is it using its own independent installation of PostgreSQL?
Even better answer..
cov-admin-db backup c:/mybackupfile
When you installed Coverity Integrity Manager, it asked you if you want it to install and manage a PostgreSQL instance or if you want to connect to your own existing PostgreSQL instance that you then have to manage.
If you chose the former, then you would use the provided cov-admin-db command.
If you chose the latter then presumably you already do regular back-ups of your databases with *pg_dump*, you should do the same for the Coverity database.
Without knowing which of the two you chose, it's not clear which of the two answers already given is correct.
You can check which option you chose by looking in the file /config/system.properties - if the first line is "*embedded_db=true*" then use the cov-admin-db command which is documented in the manual as well as in its own --help option.
If it does use PostgreSQL, then there should be a pg_dump utility somewhere in the PostgreSQL installation.
Taking backups using pg_dump is very well explained in the manual:
http://www.postgresql.org/docs/current/static/backup-dump.html
http://www.postgresql.org/docs/current/static/app-pgdump.html
Database: DB2 v9.5 on AIX
Scenario: I have 2 instances- db2inst1 and db2inst2. I created db2inst1 first. I went ahead and created db2inst2 next and I do 'db2set -all' on db2inst2 instance I see this:
[g] DB2INSTDEF=db2inst1
I would like to reset DB2INSTDEF and make it not show up when I do 'db2set -all' (other than dropping and recreating db2inst1).
Thanks.
DB2INSTDEF does not apply on AIX (it's only used on Windows systems), so it doesn't really matter if (or what) it is set to. Why is this a problem?
If you really want to eliminate the variable, then run (as root):
/opt/IBM/db2/V9.5/adm/db2set -g DB2INSTDEF=
(The path /opt/IBM/db2/V9.5 may be slightly different on your system, depending on whether you installed DB2 into the default location or not).