After trying to run PostgreSQL 9.1 on Amazon Web Services this error has been turning up in the database and application logs. Reinstalling on a different AWS VM has not helped. Strangely the error goes a way after a few moments of activity, only to return once the system goes idle for a while.
The PostgreSQL data populating the database was recently WAL streamed from a CentOS VM and restarted as a read-write master.
Searches for "EINTR" in the PostgreSQL source turns up plenty of results, but none that jumps out as related to opening base files. Quite a few references to "could not open file". These looked promising:
src/backend/storage/file/copydir.c
src/backend/storage/file/fd.c
src/port/open.c
Related
I use MongoDB 4.2 on my local machine (windows 10). I have not changed any configurations, so the default behavior of only accepting local connections should be in place. (I only need to access it locally)
I was running a script that was reading data from my MongoDB, there are no writes to the db in this script. When all the numbers were crunched I noticed weird results, and saw that my database was suddenly gone. I checked my dbpath and the data was gone from there too! Could it be a hack, or was it MongoDB that dropped both the database and the raw data in the dbpath?
I've seen similar questions on this forum, mostly resolved by the author forgetting to reroute to the correct dbpath, which is not the case here. I've checked the log but the log seems to be very limited (I restarted mongod and could only see logging happening after the restart).
MongoDB does not delete all of the files in its data directory.
Most likely either you are checking in the wrong place or something external to MongoDB deleted its files.
I am new to freenode and postgresql. I am trying to migrate from mysql to postgresql. Currently trying to set up server for ssl. Have created my server certs and configured the .conf files for ssl according to the manual as far as I can see. Trying to restart postgre sql service fails. Windows event log gives me an event ID of 0 and says
pg_ctrl could not start server examine the log output.
I can't find any log detailing the failure to start in the postgresql folders.
I have tried to register the pgevent.dll as advised by the postgresql manual (18.11 of most recent version), but I get an error message
The module "C:postgreSQL\pg10\lib\postgresql\pgevent.dll" was loaded but the entry-point DllRegisterServer was not found
I believe that means it is either not a registrable dll or it's corrupt.
Can anyone please advise how I can track on Windows the error that is causing Postgre to fail to start?
I have once before mounted this same database, so I am confident that I have the correct credentials.
During the last session that I had it mounted I was experimenting with my queries, visuals etc. and the session all of a sudden crashed.
Then when I reloaded slamdata, the mount for my database was gone.
Obviously I then tried to remount the same database with the same credentials in order to continue my work. However when I did this I got an error:
There was a problem saving the mount: An unknown error ocurred: 500 ""
And then there is a never ending spin wheel that sits on the mount button. I can leave this pop up and go to the original screen, but nothing occurs. And then if I try to remount again the same error occurs.
I have verified that I can still access my db and collections using robomongo. So if anyone knows what this error message refers to please let me know! I have yet to find its meaning online.
Note: I have already tried uninstalling and reinstalling/ restarted my computer.
In SlamData 4.2.1 this bug has been identified and fixed an issue with the MongoDB connecter that would corrupt the metastore if you use the _id field in a query. The fix is available in the SlamData 4.2.2 release soon
Below is the fix:
Delete the current metastore. Below is the location of this file for each supported operating system:
Mac OS:
$HOME/Library/Application Support/quasar/quasar-metastore.db.mv.db
Microsoft Windows:
%HOMEDIR%\AppData\Local\quasar\quasar-metastore.db.mv.db
Linux (various vendors):
$HOME/.config/quasar/quasar-metastore.db.mv.db
Open a terminal and switch to the location that you stored SlamData into. You should find a quasar-web.jar file in the following location based on your installed operating system based on default installation paths:
Mac OS:
/Applications/SlamData 4.2.1.app/Contents/java/app/quasar-web.jar
Microsoft Windows:
C:\Program Files (x86)\slamdata 4.2.1\quasar-web.jar
Linux (various vendors):
$HOME/SlamData 4.2.1/quasar-web.jar
Run the following command in a terminal:
java -jar quasar-web.jar initUpdateMetaStore
This will rebuild your metastore. Once complete it will return you to your operating system prompt.
Rerun the SlamData application as you normally would
Remount your database
At this point in time you can access your saved workspaces.
NOTE: You will not want to open the workspace you were using that caused this issue as it will cause the same problem.
I was trying to follow the instructions from postgresqltutorial to load a sample database into postgresql using pgadmin. But after the database was restored(since I can query data from the database), the process watcher just won't go away, and it keeps saying that the command is "running"(as of this writing, it has been running for over 400 thousands seconds, but the size of the sample database is just a few megabytes). Reboot and reinstallation couldn't fix the problem.
Here are some screen shots:
And when I click "click here for details":
I am using postgresql 9.6 with pgadmin4 on windows 10. So what's going on here? Is it a bug? How can I get rid of the process watcher?
I had the same issue with posgresql 9.5 and pgAdmin4 on Windows 7. I solved it without loosing server list by opening %APPDATA%\pgAdmin\pgadmin4.db file with SQLite Manager (Firefox Add-on) and deleting all entries from the 'process' table.
This is a bug in pgAdmin4 & reported,
https://redmine.postgresql.org/issues/1679
close pgAdmin, restart the system, open %APPDATA% and erase the folder pgAdmin and the pgAdmin is Ready to start without errors.
Greetings
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