When i tried running my test cases in rubymine it is taking long time and when i force stop it, asking for password. I m not sure what is root cause, because when i run it in local/dev before it was working but now it is not working.
Any suggestions would really help and Thanks for your time
Testing started at 2:23 PM ...
Running in Environment: test
Using temp directory: temp/0f9fbd55b6eae33875fdd42ef51ee106
Downloading /home/username/.priv/.td_connection to temp/0f9fbd55b6eae33875fdd42ef51ee106/.td_connection
Process finished with exit code -1
username#server's password:
Related
I'm working on setting up point in time backups for a PSQL server that I have running, and I'm following a tutorial for an earlier version. I'm trying to figure out what the specific directory is for the DB cluster in PSQL-12 so that I can clear out that directory and test what I've setup. In the video, he runs a recursive remove on the PSQL-10 directory /var/lib/postgresql/10/main, and is still able to start the PSQL-10 service again when he's finished the restoration.
When I attempted it, I ran the recursive remove on the directory /var/lib/pgsql/12/data/ because the command SHOW data_directory; told me that is where my server's cluster data is stored. Removing all the data, however, messes up the postgresql-12.service, so I can't start it back up when I've completed the recovery.
This is displayed when I restore the backup and run systemctl start postgresql-12.service:
Process: 26672 ExecStart=/usr/pgsql-12/bin/postmaster -D ${PGDATA} (code=exited, status=1/FAILURE)
Dec 31 11:07:29 localhost.localdomain systemd[1]: Failed to start PostgreSQL 12 data....
I've tried making a backup of the working /data/ directory and doing a diff -qr to see what files differ between the working backup and the point in time backup, but coping those files from the working directory to the PIT directory doesn't seem to fix the issue, and I'm still unable to start the postgresql-12.service. It seems, however, that I am able to start the service back up successfully if I just do a mass copy of the working directory to /var/lib/postgresql/10/main.
Can someone please point me in the right direction? I've done plenty of research trying to find the working cluster directory so I can just erase table information and work on a PIT recovery without messing up the core application prereqs (such as the service), but I can't seem to find the information I'm looking for. Any assistance would be greatly appreciated! Additionally, if there's a way to spot this directory more quickly in the future, either by a command or looking at the files within, I would love to know so I can implement this procedure on different PSQL versions. Thank you!
I create a job to clean the database every day at 01:00.
According to statistic run OK from 3 months.
But today i realize the database size was very big so i check the jobs and hasn't run for one month.
Properties say last run was '10/27/2014' and statistics confirm run successful.
Also say next run will be '10/28/2014' but looks like never run and stay frozen since then.
(I'm using dd/mm/yyyy format)
So why stop running?
There is a way to restart the job or should i go and delete and recreate the job?
How can i know a job didn't run?
I guess i can write a code if job isn't successful but what about if never execute?
Windows Server 2008
PostgreSQL 9.3.2, compiled by Visual C++ build 1600, 64-bit
The problem was the pgAgent service wasn't running.
When I Restart the Postgres service:
Postgres service stop
pgAgent stop because is a dependent service
Postgres service start
but pgAgent didn't
Here you can see pgAgent didn't start.
I just got mongo running yesterday, I entered C:\mongodb\bin\mongod.exe, then bought up another command prompt and entered the same thing again, and it was working fine. I ended up shutting it down wrong and now im getting unable to create/open lock file: data/db/mongod/lock because it is being used by another process. I have tried all of what im seeing but getting not recognized errors. It was a little test db, so i want to just get rid of it so i can open mongo again. I deleted the file.lock from my db file as well, but not sure it worked seems like it left and was back again, but it might just be me.
I know this is a super easy problem, just not getting it. Where should i be entering these command, im following the instructions, but i know im not inputing them in the right place because none of them work at all. I tried just inputting them, in C, in C: data/db, i entered C:\mongodb\bin\mongod.exe left it open and opened another command prompt and enter everything in there to. I can't just reset mongodb? Does anyone know what I'm missing maybe it's i have no windows knowledge at all, i'm trying to use it because i know javascript a little php/sql and i'm trying to learn node.js when i had it working in the shell it was great, but with this set up stuff i'm lost. I'm understanding everything there saying but just not where to do it i think.
Someone please lol, i just uninstalled mongodb and reinstalled and same problem.
mongod --repair (is not recognized as internal, or external command)
db.repairDatabase(same,,is not recognized as internal, or external command);
\data\db\mongod.lock (asks how i want to open it)
This is my set up, i think mongod is the problem, but can't get rid of it.
Computer>Windows>data>db
_tmp
joural
local
local.ns
mongod locked file
edit*** not sure if i removed the lock or not but i got it to work. I should have wrote down how i did it but pretty sure this was it.
open a command prompt cd\ enter it cd mongodb\bin enter it open another command cd\ enter it cd mongoDb\bin enter it. in the first command enter mongod then in the other one enter mongo. Don't know if this is right way, but i got me to be able to play with mongodb like i wanted.
try to remove mongod.lock and journal, then restart.
I have a web app that uses postgresql 9.0 with some plperl functions that call custom libraries of mine. So, when I want to start fresh as if just released, my build process for my development area does basically this:
dumps data and roles from production
drops dev data and roles
restores production data and roles onto dev
restarts postgresql so that any cached versions of my custom libraries are flushed and newly-changed ones will be picked up
applies my dev delta
vacuums
Since switching my app's stack from win32 to CentOS, I now sometimes (i.e., it seems, only if and only if I haven't run this build process in "a while"--perhaps at least a day) get an error when my build script tries to apply the delta:
psql: could not connect to server: No such file or directory
Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
Specifically, what's failing to execute at the shell level is this:
psql --host=$host -U $superuser -p $port -d $db -f "$delta_filename.sql"
If, immediately after seeing this error, I try to connect to the dev database with psql, I can do so with no trouble. Also, if I just re-run the build script, it works fine the second time, every time I've encountered this. Acceptable workaround, but is the underlying cause something to be concerned about?
So far in my attempts to debug this, I inserted a step just after the server restart (which of course reports OK shutdown, OK startup) whereby I check the results of service postgresql-dev status in a loop, waiting 2 seconds between tries if it fails. On my latest build script run, said loop succeeds on the first try--status returns "is running"--but then applying the delta still fails with the above connection error. Again, second try succeeds, as does connecting via psql outside the script just after it fails.
My next debug attempt was to sleep for 5 seconds before the first status check and see what happens. So far this seems to solve the problem.
So why is pgsql not listening on the socket after it starts [OK] and also has status running ok, for up to 5 seconds, unless it has "recently" been restarted?
The status check only checks whether the process is running. It doesn't check whether you can connect. There can be any amount of time between starting the process and the process being ready to accept connections. It's usually a few seconds, but it could be longer. If you need to cope with this, you need to script it so that it checks whether it is possible to connect before proceeding. You could argue that the CentOS package should do this for you, but it doesn't.
Actually, I think in your case there is no reason to do a full restart. Unless you are loading libraries with shared_preload_libraries, it is sufficient to restart the connection to pick up new libraries.
I'm trying to install PostgreSQL on Cygwin as a user and i'm getting stuck on the part where I have to create a database server, after i execute the pg_ctl command, it just prints "server starting" and runs in the foregorund indefinitely, here's a picture of what I'm talking about:
http://postimg.org/image/oh7ucgt9h/
Im generally a beginner to databases so any pointers would be great.
Chances you are hanging allocating shared memory. Please go with the native Windows build instead. It is far easier to manage.
However if you insist, make sure the ipc-daemon is running before you run PostgreSQL. This will probably solve your problem.
You could run:
ipc-daemon --install-as-service
net start ipc-daemon
And this should do it.