1

I'm trying to run PostgreSQL on Windows Server 2008 R2 as a dependency of JFrog Artifactory. When I try to start the service, the following error occurs:

The postgresql-x64-9.5 service on local computer started and then stopped. Some services stop automatically if they are not in use by other services or programs."

What i have tried:

  • Deleting the postmaster.pid file because it may still use this file from previous sessions.
  • Deleting the old processes of "postgres" left from the latest run.

Those recommendations were taken by this post of stack overflow : click here

On the post that i writed above i have tried the answers.

Than i tried to launch the postgres windows service from command line and i got this error:

[4200] FATAL:  lock file "postmaster.pid" already exists
[4200] HINT:  Is another postmaster (PID 6172) running in data directory "H:/data/9.5"?

Does anyone know why this can occur?

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
JimShapedCoding
  • 849
  • 1
  • 6
  • 17
  • 1
    That's a generic Windows service error, not a PostgreSQL error, so it doesn't really tell us anything useful about *why* startup failed. The place to start is to look for PostgreSQL's logs, and include them in any question you ask somewhere it's topical (like [SuperUser](https://superuser.com/)). – Charles Duffy Jan 08 '20 at 18:28
  • 1
    That said, this question is as a whole off-topic here (and so is the other instance you linked). Stack Overflow is for questions about *writing code*, not system administration. – Charles Duffy Jan 08 '20 at 18:30
  • 1
    ...so, the `FATAL: lock file "postmaster.pid" already exists` problem will be solved by killing any processes using that lockfile, and then deleting the file if it still exists. Once you've done that, what error do you get then? (If the pidfile is being automatically recreated, it's probably the service doing that; disable it for the duration of your investigation). – Charles Duffy Jan 08 '20 at 18:34
  • 1
    ...which is to say -- the steps you already followed definitely do solve *that specific* error, but there's probably a different error that happens afterwards; we need to know what that one is too. (If it turns out that the other failure mode leaves behind a pidfile, then that would clarify how you're getting back into the place where a pidfile needs to be deleted before you can *reach* the deeper error to investigate it). – Charles Duffy Jan 08 '20 at 18:35

1 Answers1

-3

I solve this issue by uninstalling postgres from my machine and then installing if again

Jibril14
  • 11
  • 4