I was recently updating my postgres from 9.5 to 9.6.2 (installed with home-brew, though the old binaries were downloaded from postgresql directly), and I encountered a strange problem. I have been following this guide, and everything went okay. I had to modify some commands as my encoding info was strange, but everything worked (modified commands listed below.)
initdb --local=C /usr/local/var/postgres -E utf8 --lc-ctype=en_US.UTF-8
pg_upgrade -d /usr/local/var/postgres96 -D /usr/local/var/postgres -b /Users/MyUser/Downloads/pgsql/bin/ -B /usr/local/Cellar/postgresql/9.6.2/bin/
Note: I moved the old data cluster to posgres96 before beginning the process.
However, none of the data transferred over. I ran du -sh /usr/local/var/*/, and all of my data is still in postgres96, but none transferred over to the new cluster.
4.0K /usr/local/var/db/
80K /usr/local/var/homebrew/
48K /usr/local/var/log/
141M /usr/local/var/postgres/
386M /usr/local/var/postgres96/
0B /usr/local/var/run/
I re-ran everything, and noticed in the output of pg_upgrade there was a weird anomaly.
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for roles starting with 'pg_' ok
Creating dump of global objects ok
Creating dump of database schemas
ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.
Performing Upgrade
------------------
Analyzing all rows in the new cluster ok
Freezing all rows on the new cluster ok
Deleting files from new pg_clog ok
Copying old pg_clog to new server ok
Setting next transaction ID and epoch for new cluster ok
Deleting files from new pg_multixact/offsets ok
Copying old pg_multixact/offsets to new server ok
Deleting files from new pg_multixact/members ok
Copying old pg_multixact/members to new server ok
Setting next multixact ID and offset for new cluster ok
Resetting WAL archives ok
Setting frozenxid and minmxid counters in new cluster ok
Restoring global objects in the new cluster ok
Restoring database schemas in the new cluster
ok
Copying user relation files
ok
Setting next OID for new cluster ok
Sync data directory to disk ok
Creating script to analyze new cluster ok
Creating script to delete old cluster ok
Upgrade Complete
It seems like the database schemas never got dumped? Regardless, all of my data is trapped in postgres96, and I can't get it out. Any help or insight would be appreciated.
Edit: I ended up just reinstalling an older postgres and dumping my data into the new server (which worked). I'd still be interested to know why pg_upgrade wasn't working though.
Related
I am trying to run a pg_upgrade on my existing 12.8 postgres and migrate it to 14.3 with docker based installation. I got the below error :
Performing Upgrade
------------------
Analyzing all rows in the new cluster ok
Freezing all rows in the new cluster ok
Deleting files from new pg_xact ok
Copying old pg_xact to new server ok
Setting oldest XID for new cluster ok
Setting next transaction ID and epoch for new cluster ok
Deleting files from new pg_multixact/offsets ok
Copying old pg_multixact/offsets to new server ok
Deleting files from new pg_multixact/members ok
Copying old pg_multixact/members to new server ok
Setting next multixact ID and offset for new cluster ok
Resetting WAL archives ok
Setting frozenxid and minmxid counters in new cluster ok
Restoring global objects in the new cluster ok
Restoring database schemas in the new cluster
template1
myschema
*failure*
Consult the last few lines of "pg_upgrade_dump_1.log" for
the probable cause of the failure.
Can anyone help me with the location of pg_upgrade_dump_1.log and pg_upgrade_internal.log files?
Yes, as the user a_horse_with_no_name mentioned in his comment logs are created in the location where you executed pg_upgrade.
Several files are created like logs dumps and others.
What I am trying to accomplish is a recovery using a continuous archive backup.
I am running a vm of CentOS 6.8 and Postgres 9.1 Postgres 9.1 is the same as the DB that I am pulling from.
I installed Postgres and initialized the DB, started up fine.
Then, following these directions: https://www.postgresql.org/docs/9.3/static/continuous-archiving.html
Stopped the destination pSQL server (as root: service postgresql-9.1 stop)
Copied the destination cluster data folder to the side (as postgres)
Removed the cluster data files (as postgres)
Copied in my source data folder (as postgres)
Copied WAL files into a clean pg_xlog folder under the data folder (as postgres)
Created a recovery.conf file which contained:
restore_command = 'cp /var/lib/pgsql/database_sample_backup/wal_archives/0A/%f %p'
This being another location for the WAL files other than the copy I placed in pg_xlog (was not sure if I needed both)
But when I attempt to restart my server, it fails. (as root: service postgresql-9.1 start)
My pgstartup.log at one point spit out "runuser: cannot set groups: Operation not permitted" but it doesn't consistently do this with every attempt to start.
I've also tried turning off archiving and replication directive in postgres.conf (so that it can run stand alone) and tried copying over the pg_hba.conf from the new DB I had created to see if they would resolve the issue. Neither did.
I've also done a netstat -ntap | grep 5432 which confirmed that I don't have anything else running on the port.
What else can I provide in the form of details, and what else my I attempt in this restoration process.
Thank you for your help!
At my work I was running a complex query. I cancelled it and went home yesterday. This morning in the back the query was impossible to be terminated, also with the 'terminate backend' functionality. A colleague of mine restarted the host machine where postgres is installed. After the machine restart, the postgres database sever would not start up.
In my log files I see the error:
'pg_ctl: this data directory appears to be running a pre-existing postmaster'
I am not sure how to handle this problem. I could try to fix it or try to extrapolate the data from the save files. What is the most logical step to take and do you know how to fix this?
Earlier it gave this error message :
2016-01-28 15:52:33 GMT FATAL: lock file "postmaster.pid" already exists
2016-01-28 15:52:33 GMT HINT: Is another postmaster (PID 2100) running in data directory "C:/PostgreSQL/9.1/data"?
UPDATE... I located the file postmaster.pid and deleted it. Now I am restarting the computer and hoping it will start.
UPDATE... It works now. I rebooted the computer and postgres just instantly started. Happy as a child but at the same time not fully satisfied because of the following forum: https://superuser.com/questions/553045/fatal-lock-file-postmaster-pid-already-exists . Here it is stated to NEVER delete the postmaster.pid because of possible data corruption. So because of that I will backup all databases I have in postgres now.
So if anyone can share some more light on my ICT adventure of today I would be very satisfied. That is why I will not state that this question is answered, since I have no idea what went wrong and perhaps will run into it again someday.
The explanation is pretty straightforward. PostgreSQL writes the process ID to a file called postmaster.pid — the presence of the file is supposed to indicate that the server is running. When the PostgreSQL shuts down cleanly, it removes the postmaster.pid file.
However, when your colleague restarted the host machine, the PostgreSQL server got killed without having had a chance to remove the postmaster.pid file. Therefore, when you tried to start PostgreSQL, the presence of the file made it look complain that the server was already running.
This answer provides more complete advice. In general, you should never delete postmaster.pid for no good reason, because it's supposed to help prevent two servers from running at once on the same data files. However, if you are certain that the process indicated by the postmaster.pid file is already dead, then by all means just delete the stale PID file manually.
In windows Delete all running postgres processes and start the service
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 apologize for the long post. I have a Postgresql 9.3 server running on a Amazon linux AMI. I also have a compressed dump file from another server which I created using pg_dumpall. Now, I want to restore the data from this dump file in my Postgres. However, I want to load this data into a specific location (say /data).
I'm having a fresh installation of Postgres. So when I tried to do a:
sudo service postgresql93 start
I got an error message asking me to initialize the db. So I did a:
sudo service postgresql initdb
which created the required files in /var/lib/pgsql93/data. After that, I changed the 'data_directory' configuration in /var/lib/pgsql93/data/postgresql.conf and pointed it to /data (I had to do this as root user. I couldn't open the file as the default user).
Now when I try to do a
sudo service postgresql93 start
it fails to start, and when I check the /var/lib/pgsql93/pg_startup.log file, it says:
FATAL: "/data/postgresql" is not a valid data directory
DETAIL: File "/data/postgresql/PG_VERSION" is missing.
So I copied the files from the default (/var/lib/pgsql9.3/data) to /data, changed the permissions to 700 and owner to postgres.
However, when I try to start the service again, it still fails, and in the pgstartup.log, it only says:
LOG: redirecting log output to logging collector process
HINT: Future log output will appear in directory "pg_log".
And when I check the log in /data/pg_log, it says:
LOG: database system was shut down at 2014-12-30 21:31:18 UTC
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
What else could be the problem? I haven't restored the data yet. I just have the files which were created by the initdb command.
#BMW http://www.linuxquestions.org/questions/linux-server-73/change-postgresql-data-directory-649911/ is exactly what I was looking for. Thanks.