This parameter enables the logging collector, which is a background process that captures log messages sent to stderr and redirects them into log files. This approach is often more useful than logging to syslog, since some types of messages might not appear in syslog output. (One common example is dynamic-linker failure messages; another is error messages produced by scripts such as archive_command.) This parameter can only be set at server start.
It is possible to log to stderr without using the logging collector; the log messages will just go to wherever the server's stderr is directed. However, that method is only suitable for low log volumes, since it provides no convenient way to rotate log files. Also, on some platforms not using the logging collector can result in lost or garbled log output, because multiple processes writing concurrently to the same log file can overwrite each other's output.
The logging collector is designed to never lose messages. This means that in case of extremely high load, server processes could be blocked while trying to send additional log messages when the collector has fallen behind. In contrast, syslog prefers to drop messages if it cannot write them, which means it may fail to log some messages in such cases but it will not block the rest of the system.
- postgres logging_collector sending to two directories simultaneously
- Postgres initdb: How to set logging_collector=on in the generated postgressql.conf file
- Postgres: How to convert SQL result into column name & value
- How do I turn SQL logging on in Postgres 8.2?
- pgBadger - generated report is empty but postgres log has events
- Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
- Re: should we enable log_checkpoints out of the box?
- Re: Printing backtrace of postgres processes
- Remove extra Logging_collector check before calling SysLogger_Start()
- Re: Log message for GSS connection is missing once connection authorization is successful.