1. SysLogger System log collector
This article describes how to start the PostgreSQL log collector, configure the directory and size of the log file, and many configuration parameters associated with the log file. It also shows some subtle changes to log files before and after PostgreSQL10.0. This section will analyze the internals of the SysLogger log collector, and you will have a clearer understanding of how Logger works.
1.1 SysLogger Startup entry
PostgreSQL is a client/server (C/S) architecture. The main function in the main. C (/ SRC /backend/main) file is the entry point for the initialization code of the entire service. The main function will be judged according to the boot parameter options and go to different branches. The postmaster daemon is then initialized, mainly in the postmaster.c file (in/SRC /backend/postmaster/ directory). The postMaster daemon is responsible for starting and shutting down the entire system. It listens to and accepts connection requests from clients, and does not assign a Postgres service to each request. All requests from the client connection then interact directly with the Postgres process, rather than through the PostMaster daemon.
SysLogger initialization of the log collector inlet is SysLogger_Start function (/ SRC/backend/postmaster/SysLogger. C). Before initializing the log collector, the GNC global variable parameter Logging_collector is determined (it corresponds to Logging_collector in the postgresql.conf configuration file, read the PostgresQL configuration management log message for more details). If this parameter is true, the logger process is enabled. Otherwise, the logger process exits and is not enabled.
1.1.1 SysLogger Indicates the name of the log collector process
The SysLogger log collector daemon process is called logger. When the SysLogger process is initialized, the global variable MyBackendType (BackendType MyBackendType;) is initialized. Process initialization: B_LOGGER operation (MyBackendType = B_LOGGER;) GetBackendTypeDesc() is used to obtain the daemon name when the daemon is created. PostgreSQL 13.2 supports the following types of background daemons:
typedef enum BackendType
{
B_INVALID = 0,
B_AUTOVAC_LAUNCHER,
B_AUTOVAC_WORKER,
B_BACKEND,
B_BG_WORKER,
B_BG_WRITER,
B_CHECKPOINTER,
B_STARTUP,
B_WAL_RECEIVER,
B_WAL_SENDER,
B_WAL_WRITER,
B_ARCHIVER,
B_STATS_COLLECTOR,
B_LOGGER,
} BackendType;
Copy the codeHere are the process names for each daemon (enumerated values) :
1.1.2 PostgreSQL The PostgreSQL daemon process is enabled by default
Not all daemons are started by default. Some need to be started manually in the postgresql.conf configuration file, such as the log collector with the logging_collector parameter set to on. By default, PostgreSQL only enables CheckPointer, Background Write, Walwriter, Autovacuum Launcher, STATS Collector, and Logical Replication Launcher These background daemons are shown in the following figure:
1.1.3 SysLogger Log collector startup process
SysLogger Overall system log initialization flowchart
The overall initialization process of the SysLogger log collector is shown in the following flowchart:
When initializing the log collector, the log directory is created according to the parameter (log_directory) in the postgres.conf configuration file. By default, the owner of the log directory has read, write, and execute permissions. As follows:Copy the code
#ifndef S_IRWXU
#define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR)
#endif
int
MakePGDirectory(const char *directoryName)
{
return mkdir(directoryName, pg_dir_create_mode);
}
Copy the codeAfter the directory is created, obtain the current system time, format the time according to the value of log_filename in the postgresql.conf configuration file, and generate a new log file. Then open the log file in the file access mode + A. If the log file does not exist, create a new one, adjust the properties of the log file, and set the stream buffer of the log file to line cache (_IOLBF). After the log file is created successfully, the fork_process() function is called to create the Logger child process(fork_process is a wrapper of fork function, including the return value matching fork.), and the memory related parameters (OOM) are set internally in the child process. The function then returns the PID of the process.
Other work processing is carried out according to the value of PID. If PID is 0, it indicates that in the child process, The child process initializes global variables related to the child process status, registers the parent process status signals, closes the read pipe, closes the listening socket in the postmaster parent process, and closes the memory data associated with the parent postmaster process. Then enter the SysLoggerMain() function to actually start the processing of the Logger logger process. In the parent process, the buffer data of stout, stderr and other file descriptors is first refreshed, then the stdout and stderr file descriptors are redirected to the pipe syslogPipe[1] D write side, and then the pipe write side and log file descriptor handle syslogFile are closed. The postmaster parent will never write data to the log file.
The parent process postMaster then returns the child process PID of the Logger logger logger collector. This child process PID will be used in the ServerLoop() function of the PostMaster parent process. The ServerLoop() function is the primary empty loop handler for the daemon postmaster (parent process). This function is an infinite loop (for(; 😉 ), This function is responsible for checkPointer, Background write, Walwriter, Autovacuum Launcher, and STATS Manages and maintains the status of auxiliary daemons such as Collector (statistical data collection process), Logger (system log process), and Archiver (pre-write log archive process). If the PID of one of the daemons is lost, a new daemon is created immediately.
For example, for the helper processes logger, Background Writer, Walwriter, AutoVACUUM Launcher, Stats Collector and Logical Replication Launcher shown in the following figure, If one of them is killed manually, the postmaster daemon will check the kill status of the corresponding auxiliary child process and the corresponding signal (if the highest level (debug5) log is enabled, the corresponding signal value will be printed). Then immediately re-fork () a corresponding child process. Note: I combined with the code logic personally tested, the actual situation and logic is consistent, matching.
In addition, the ServerLoop() function is responsible for listening for the user’s connection requests. For each request sent by the user, PostMaster will fork a child process (Postgres) to process it, and all subsequent requests from that user will be processed. Operations such as adding, deleting, modifying and checking databases, tables and indexes are processed by the Postgres process. So PostgreSQL is a multi-process client/server model.
if (selres > 0)
{
int i;
for (i = 0; i < MAXLISTEN; i++)
{
if (ListenSocket[i] == PGINVALID_SOCKET)
break;
if (FD_ISSET(ListenSocket[i], &rmask))
{
Port *port;
port = ConnCreate(ListenSocket[i]);
if (port)
{
BackendStartup(port);
/* * We no longer need the open socket or port structure * in this process */StreamClose(port->sock); ConnFree(port); }}}}Copy the codeUpon receiving a connection request from the user, the ServerLoop() function will first create a local connection ConnCreate() corresponding to the request. The BackendStartup() function handles the fork of the child process. When the fork process succeeds, the parent process will put the PID of the child process to the active process PID list in the back end, which is done by the dlist_push_head() function.
2. To summarize
The logger system log collector introduced by PostgreSQL 8.0 has been initialized and summarized in detail. Through the reading of this article, you will improve your understanding of logger auxiliary process. At the same time, it also helps to log the work of PostgreSQL database services. The next section continues the analysis of how other helper processes work.