Postgresql server does not start. PostgreSql service does not start

pg_ctl init [ -s ] [ -D datadir] [ -o initdb-options ]

pg_ctl start [ -w ] [ -t seconds] [ -s ] [ -D datadir] [ -l file name] [ -o parameters] [ -p path] [ -c ]

pg_ctl stop [ -W ] [ -t seconds] [ -s ] [ -D datadir] [ -m s | f | i]

pg_ctl restart [ -w ] [ -t seconds] [ -s ] [ -D datadir] [ -c ] [ -m s | f | i ] [ -o parameters ]

pg_ctl reload [ -s ] [ -D datadir ]

pg_ctl status [ -D datadir ]

pg_ctl promote [ -s ] [ -D datadir ]

pg_ctl kill signal_name process_id

pg_ctl register [ -N servicename] [ -U username] [ -P password] [ -D datadir] [ -S a | d ] [ -w ] [ -t seconds] [ -s ] [ -o parameters ]

pg_ctl unregister [ -N servicename ]

The server starts in start mode. The process runs in the background and standard input is associated with /dev/null (or nul on Windows). By default, on Unix-like systems, server output and errors are written to the standard output (not error) device pg_ctl. The output of pg_ctl should be redirected to a file or process, such as the log rotation application rotatelogs ; otherwise, postgres will write output to the control terminal (in the background) and remain in the shell process group. On Windows, server output and errors are redirected to the terminal by default. You can change this behavior and direct the server output to a file by adding the -l switch. We recommend using the -l switch or redirecting the output.

To stop the server, stop is used. You can stop in three modes, specified by the -m flag. The default mode is "Smart", which waits for all active client connections and remote backup processes to complete. If the server is running in hot standby mode, then recovery and streaming replication will stop as soon as all client sessions are completed. "Fast" mode does not wait for client sessions to close and interrupts remote backup processes. All active transactions are rolled back and clients are forced to disconnect, after which the server stops. The "Immediate" mode immediately interrupts all processes and stops the server, which leads to the need to recover after a failure at the next start.

To stop and then start the server, restart is used. In this case, the flags of the postgres command are available. restart may not work if a relative path to the data storage directory was specified on the command line when starting the server.

To reread the configuration (postgresql.conf, pg_hba.conf, etc.), reload is used, and the postgres process receives the SIGHUP system signal. This allows you to apply changes without completely restarting the server.

To check the status of the cluster, status is used. If the cluster is running, the PID of the process will be displayed, as well as a command with the arguments used when starting. If the cluster is stopped, the process will return exit status 3. If the data storage directory is not specified, then the process will return exit status 4.

To switch the standby server to primary mode, use promote . In this case, the server stops working in recovery mode and starts working in read-write mode.

To send a signal to a process, kill is used. This is especially useful in a Microsoft Windows environment that does not have a kill command in the snap-in. For a list of available signals, see --help .

To register as a system service under Microsoft Windows, register is used. The -S flag sets the service startup mode, either “auto” (at OS startup) or “demand” (on request).

To remove a registered service in Microsoft Windows, unregister is used.

Options

C
--core-file

On platforms where this is supported, the server will attempt to capture memory snapshots when there are crashes. This makes it possible to diagnose and prevent potential problems in the future. -D datadir
--pgdata datadir

Specifies the location of the cluster configuration files. If not specified, the value of the PGDATA environment variable is used. -l file name
--log file name

Outputs log data to filename. The file is created if it does not already exist. In this case, the umask is set to 077, which prevents other users from accessing this file. -m mode
--mode mode

Sets the cluster stop mode. mode takes the values ​​smart , fast , or immediate , or the first letter of each available value, such as s . If the flag is omitted, then smart is used. -o parameters

Specifies the flags that will be passed to postgres.

The value must be framed with single or double quotes to ensure group integrity. -o initdb-options

Specifies the flags that will be passed to initdb.

The value must be surrounded by single or double quotes to ensure group integrity. -p path

Specifies the location of the postgres application. By default, the same path is used where pg_ctl is located, or, if this fails, the installation path is taken. Most often there is no need to use this parameter, except in non-standard situations.

init accepts parameters similar to initdb . -s
--silent

Display only errors, without informational messages. -t
--timeout

The maximum time (in seconds) to wait for the server to start or stop. The default is 60 seconds. -V
--version

Prints the version of pg_ctl and aborts execution. -w

Waits for startup or shutdown to complete. This is the default mode for stop but not start operations. During the startup phase, pg_ctl continuously tries to connect to the server. During the stop phase, pg_ctl checks for the presence of a PID file. This parameter allows you to set the input of a control word for SSL at server startup. pg_ctl returns an exit code based on the result of the start or stop operations. -W

Ignore waiting for the server to start or stop. This behavior is the default for startup and restart modes. -?
--help

Print help for the pg_ctl command and abort execution.

Windows-specific options

N servicename

The name of the system service to register. It is used as a system and display value. -P password

Password of the user starting the service. -S startup type

System service startup type. Can take the values: auto , or demand , or be represented by the first letter of the name of each given value. The default is auto . -U username

The username under which the service will be launched. For domain users, you must use the DOMAIN\username notation.

I am trying to run Postgres 9.2.4 as a service on Windows 7. After installing postgres the service is working fine. However, after installing postgres as a server for another program, the service stopped working. When I try to start the service now I get a message that:

"Service postgresql-x64-9.2 - PostgreSQL Server 9.2 on Local Computer The computer started and then stopped. Some services stop automatically if they are not in use by other services or programs."

When I try to run a program that is supposed to use a database server, I get this error:

"A problem occurred when trying to log in or create a production database. Details: Could not connect to the server; May not have been able to connect to the remote connector. The application should now close"

I also encountered this error once when opening the same program:

"A problem occurred while trying to log in or create a production database. Details: FATAL: Failed to load pg_hba.conf. The application should now close."

I tried to start a service registered as local system account as well as my own account (in postgres properties properties) to no avail. I also tried restarting the computer. After many problems on the Internet, I learned that it is good to check the pg_log file. Here is the content of the last pg_log entry:

2013-05-29 14:59:45 MDT LOG: database system was interrupted; last known up at 2013-05-29 14:58:01 MDT 2013-05-29 14:59:45 MDT LOG: database system was not properly shut down; automatic recovery in progress 2013-05-29 14:59:45 MDT LOG: record with zero length at 0/175BB98 2013-05-29 14:59:45 MDT LOG: redo is not required 2013-05-29 14:59 :45 MDT LOG: database system is ready to accept connections 2013-05-29 14:59:45 MDT LOG: autovacuum launcher started 2013-05-29 15:07:00 MDT LOG: local connections are not supported by this build 2013 -05-29 15:07:00 MDT CONTEXT: line 1 of configuration file "C:/PostgreSQL/data/pg_hba.conf" 2013-05-29 15:07:00 MDT FATAL: could not load pg_hba.conf 2013- 05-29 15:07:00 MDT LOG: local connections are not supported by this build 2013-05-29 15:07:00 MDT CONTEXT: line 1 of configuration file "C:/PostgreSQL/data/pg_hba.conf" 2013 -05-29 15:07:00 MDT FATAL: could not load pg_hba.conf 2013-05-29 15:09:03 MDT LOG: received fast shutdown request 2013-05-29 15:09:03 MDT LOG: aborting any active transactions 2013-05-29 15:09:03 MDT LOG: autovacuum launcher shutting down 2013-05-29 15:09:03 MDT LOG: shutting down 2013-05-29 15:09:03 MDT LOG: database system is shut down

There seems to be problems with the pg_hba.conf file, which looks like this:

Local all all trust host all all 127.0.0.1 255.255.255.255 trust host all all 0.0.0.0 0.0.0.0 trust

As per numerous suggestions on the internet, I tried changing the top line to several different alternatives (all hosts all trust/host all 127.0.0.1/32 trust/host all 192.168.0.100/24 ​​trust, etc.). This made sense to me since the log file said that local connections are not supported by postgres and also pointed to this line. However, none of my changes had any effect. I tried restarting my computer after each change, but nothing changed.

When I looked for examples of what a pg_hba.conf file typically looks like, the examples looked a little different from my file. I noticed that in the PostgreSQL program file, in addition to pg_hba.conf, there was also a file 20130529-150444-old-pg_hba.conf, which looked much more like the examples I found online. This file has several lines of comments before these last few lines:

# TYPE DATABASE USER ADDRESS METHOD # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all::1/128 md5 # Allow replication connections from localhost, by a user with the # replication privilege. #host replication postgres 127.0.0.1/32 md5 #host replication postgres::1/128 md5

I was hoping that this was the original pg_hba.conf file, and if I replaced the new file with the contents of the old one, postgres would start working again. There is no such luck. I was hoping that more error files would be logged in the pg_log file to see if the previously reported error had gone away or if something had changed, but no more files were logged.

I searched for an online service for days and nothing I found worked. Sorry about this long question, but I wanted to be thorough and include all relevant information. I would appreciate it if anyone could shed some light on this issue or offer suggestions.

This message is intended primarily for me personally and for our support team, because... a problem similar to the one described below occurs with enviable frequency and you need to remember the basic steps to solve it.

So, the story begins with the fact that on December 30 at 11-30 I received a call with a message that one of our clients does not start our system because it cannot connect to the database (we use PostgreSql version 8.1 as a DBMS) . People explain this by saying that an hour ago the lights went out and the computer shut down incorrectly, and after turning it on, everything stopped working :)

Good users of our system know where the start button is and know that there are not two watches in the system, “one with numbers and the other with sand.” Therefore, the only thing I was able to do over the phone was to try to manually start the DBMS service, but the result was that the service did not start. I had to forward the Internet to that computer (on computers where our Internet system is installed there should not be) to be able to connect remotely.

After connecting to remote computer I tried to start the service and received the following message: “The PostgreSql Database Server 8.1 service” on “Local Computer” was started and then stopped. Some services automatically stop if they have nothing to do, such as the Performance Logs and Alerts service.” Hmm...

The problem is that at that time this was the only information available... The PostgreSql logs are empty, there are no entries in them, and the system logs are also empty.

Debugging services is not a simple process, so many developers provide mechanisms for launching a service application like an ordinary console application using keys command line. And PostgreSql is no exception in this regard; to run you need to use the following command (Hint: this command can only be run from a non-administrative user of the system, however, if you forget about this, PostgreSql will very quickly remind you of this):

postgres -D " "

We run it and look at the error message. In my case, the message sounded something like this:

FATAL - bogus data in lock file "postmaster.pid"

Of course, I was lucky, the problem turned out to be fixable. For some reason specified file turned out to be empty, and I needed to copy its contents from a working instance of the DBMS, which was not difficult.

The moral of this message is that if the database has failed, or some other problems have occurred with the system, then before reinstalling the DBMS (or the entire system) and losing all the data, you should at least try to find out what the problem is, perhaps there is all chances that you will be able to restore your performance are not the same in radical ways.

ZY Happy New Year everyone and wishes that your systems are stable and reliable and do not spoil your sleep, but even if some problems did arise, you always had options ready to deal with this situation.

This message is intended primarily for me personally and for our support team, because... a problem similar to the one described below occurs with enviable frequency and you need to remember the basic steps to solve it.

So, the story begins with the fact that on December 30 at 11-30 I received a call with a message that one of our clients does not start our system because it cannot connect to the database (we use PostgreSql version 8.1 as a DBMS) . People explain this by saying that an hour ago the lights went out and the computer shut down incorrectly, and after turning it on, everything stopped working :)

Good users of our system know where the start button is and know that there are not two watches in the system, “one with numbers and the other with sand.” Therefore, the only thing I was able to do over the phone was to try to manually start the DBMS service, but the result was that the service did not start. I had to forward the Internet to that computer (on computers where our Internet system is installed there should not be) to be able to connect remotely.

After connecting to the remote computer, I tried to start the service and received the following message: “The PostgreSql Database Server 8.1 service” on “Local Computer” was started and then stopped. Some services automatically stop if they have nothing to do, such as the Performance Logs and Alerts service.” Hmm...

The problem is that at that time this was the only information available... The PostgreSql logs are empty, there are no entries in them, and the system logs are also empty.

Debugging services is not a simple process, so many developers provide mechanisms for launching a service application like an ordinary console application using command line switches. And PostgreSql is no exception in this regard; to run you need to use the following command (Hint: this command can only be run from a non-administrative user of the system, however, if you forget about this, PostgreSql will very quickly remind you of this):

postgres -D " "

We run it and look at the error message. In my case, the message sounded something like this:

FATAL - bogus data in lock file "postmaster.pid"

Of course, I was lucky, the problem turned out to be fixable. For some reason, the specified file turned out to be empty, and I needed to copy its contents from a working instance of the DBMS, which was not difficult.

The moral of this message is that if the database has failed, or some other problems have occurred with the system, then before reinstalling the DBMS (or the entire system) and losing all the data, you should at least try to find out what the problem is, perhaps there is there is every chance that you will be able to restore your functionality in less radical ways.

ZY Happy New Year everyone and wishes that your systems are stable and reliable and do not spoil your sleep, but even if some problems did arise, you always had options ready to deal with this situation.