Где находятся логи postgresql windows

Our Blog

Ongoing observations by End Point Dev people

Dear PostgreSQL: Where are my logs?

By Josh Tolley
November 12, 2014

Photo by Jitze Couperus

When debugging a problem, it’s always frustrating to get sidetracked hunting down the relevant logs. PostgreSQL users can select any of several different ways to handle database logs, or even choose a combination. But especially for new users, or those getting used to an unfamiliar system, just finding the logs can be difficult. To ease that pain, here’s a key to help dig up the correct logs.

Where are log entries sent?

First, connect to PostgreSQL with psql, pgadmin, or some other client that lets you run SQL queries, and run this:

The log_destination setting tells PostgreSQL where log entries should go. In most cases it will be one of four values, though it can also be a comma-separated list of any of those four values. We’ll discuss each in turn.


Syslog is a complex beast, and if your logs are going here, you’ll want more than this blog post to help you. Different systems have different syslog daemons, those daemons have different capabilities and require different configurations, and we simply can’t cover them all here. Your syslog may be configured to send PostgreSQL logs anywhere on the system, or even to an external server. For your purposes, though, you’ll need to know what ident and facility you’re using. These values tag each syslog message coming from PostgreSQL, and allow the syslog daemon to sort out where the message should go. You can find them like this:

Syslog is often useful, in that it allows administrators to collect logs from many applications into one place, to relieve the database server of logging I/O overhead (which may or may not actually help anything), or any number of other interesting rearrangements of log data.

Event Log

For PostgreSQL systems running on Windows, you can send log entries to the Windows event log. You’ll want to tell Windows to expect the log values, and what “event source” they’ll come from. You can find instructions for this operation in the PostgreSQL documentation discussing server setup.


This is probably the most common log destination (it’s the default, after all) and can get fairly complicated in itself. Selecting stderr instructs PostgreSQL to send log data to the “stderr” (short for “standard error”) output stream most operating systems give every new process by default. The difficulty is that PostgreSQL or the applications that launch it can then redirect this stream to all kinds of different places. If you start PostgreSQL manually with no particular redirection in place, log entries will be written to your terminal:

In these logs you’ll see the logs from me starting the database, connecting to it from some other terminal, and issuing the obviously erroneous command “select syntax error”. But there are several ways to redirect this elsewhere. The easiest is with the pg_ctl -l option, which essentially redirects stderr to a file, in which case the startup looks like this:

Finally, you can also tell PostgreSQL to redirect its stderr output internally, with the logging_collector option (which older versions of PostgreSQL named redirect_stderr ). This can be on or off, and when on, collects stderr output into a configured log directory.

So if you see a log_destination set to stderr , a good next step is to check logging_collector :

In this system, logging_collector is turned on, which means we have to find out where it’s collecting logs. First, check log_directory . In my case, below, it’s an absolute path, but by default it’s the relative path pg_log . This is relative to the PostgreSQL data directory. Log files are named according to a pattern in log_filename . Each of these settings is shown below:

Documentation for each of these options, along with settings governing log rotation, is available in the PostgreSQL Error Reporting and Logging documentation.

If logging_collector is turned off, you can still find the logs using the /proc filesystem, on operating systems equipped with one. First you’ll need to find the process ID (pid) of a PostgreSQL process, which is simple enough:

Then, check /proc/YOUR_PID_HERE/fd/2 , which is a symlink to the log destination:

CSV log

The csvlog mode creates logs in CSV format, designed to be easily machine-readable. In fact, this section of the PostgreSQL documentation even provides a handy table definition if you want to slurp the logs into your database. CSV logs are produced in a fixed format the administrator cannot change, but it includes fields for everything available in the other log formats. For these to work, you need to have logging_collector turned on; without logging_collector , the logs simply won’t show up anywhere.

But when configured correctly, PostgreSQL will create CSV format logs in the log_directory , with file names mostly following the log_filename pattern. Here’s my example database, with log_destination set to stderr, csvlog and logging_collector turned on, just after I start the database and issue one query:


Где находятся логи postgresql windows

PostgreSQL поддерживает несколько методов протоколирования сообщений сервера: stderr , csvlog и syslog . На Windows также поддерживается eventlog . В качестве значения log_destination указывается один или несколько методов протоколирования, разделённых запятыми. По умолчанию используется stderr . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.

Если в log_destination включено значение csvlog , то протоколирование ведётся в формате CSV (разделённые запятыми значения). Это удобно для программной обработки журнала. Подробнее об этом в Подразделе 19.8.4. Для вывода в формате CSV должен быть включён logging_collector.

Если присутствует указание stderr или csvlog , создаётся файл current_logfiles , в который записывается расположение файла(ов) журнала, в настоящее время используемого сборщиком сообщений для соответствующего назначения. Это позволяет легко определить, какие файлы журнала используются в данный момент экземпляром сервера. Например, он может иметь такое содержание:

current_logfiles переписывается когда при прокрутке создаётся новый файл журнала или когда изменяется значение log_destination . Он удаляется, когда в log_destination не задаётся ни stderr , ни csvlog , а также когда сборщик сообщений отключён.


В большинстве систем Unix потребуется изменить конфигурацию системного демона syslog для использования варианта syslog в log_destination . Для указания типа протоколируемой программы (facility), PostgreSQL может использовать значения с LOCAL0 по LOCAL7 (см. syslog_facility). Однако на большинстве платформ конфигурация syslog по умолчанию не учитывает сообщения подобного типа. Чтобы это работало, потребуется добавить в конфигурацию демона syslog что-то подобное:

Для использования eventlog в log_destination на Windows, необходимо зарегистрировать источник событий и его библиотеку в операционной системе. Тогда Windows Event Viewer сможет отображать сообщения журнала событий. Подробнее в Разделе 18.11.

Параметр включает сборщик сообщений ( logging collector). Это фоновый процесс, который собирает отправленные в stderr сообщения и перенаправляет их в журнальные файлы. Такой подход зачастую более полезен чем запись в syslog , поскольку некоторые сообщения в syslog могут не попасть. (Типичный пример с сообщениями об ошибках динамического связывания, другой пример — ошибки в скриптах типа archive_command .) Для установки параметра требуется перезапуск сервера.


Можно обойтись без сборщика сообщений и просто писать в stderr . Сообщения будут записываться в место, куда направлен поток stderr . Такой способ подойдёт только для небольших объёмов протоколирования, потому что не предоставляет удобных средств для организации ротации журнальных файлов. Кроме того, на некоторых платформах отказ от использования сборщика сообщений может привести к потере или искажению сообщений, так как несколько процессов, одновременно пишущих в один журнальный файл, могут перезаписывать информацию друг друга.


Сборщик спроектирован так, чтобы сообщения никогда не терялись. А это значит, что при очень высокой нагрузке, серверные процессы могут быть заблокированы при попытке отправить сообщения во время сбоя фонового процесса сборщика. В противоположность этому, syslog предпочитает удалять сообщения, при невозможности их записать. Поэтому часть сообщений может быть потеряна, но система не будет блокироваться.

При включённом logging_collector , определяет каталог, в котором создаются журнальные файлы. Можно задавать как абсолютный путь, так и относительный от каталога данных кластера. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. Значение по умолчанию — log . log_filename ( string )

При включённом logging_collector задаёт имена журнальных файлов. Значение трактуется как строка формата в функции strftime , поэтому в ней можно использовать спецификаторы % для включения в имена файлов информации о дате и времени. (При наличии зависящих от часового пояса спецификаторов % будет использован пояс, заданный в log_timezone.) Поддерживаемые спецификаторы % похожи на те, что перечислены в описании strftime спецификации Open Group. Обратите внимание, что системная функция strftime напрямую не используется. Поэтому нестандартные, специфичные для платформы особенности не будут работать. Значение по умолчанию postgresql-%Y-%m-%d_%H%M%S.log .

Если для задания имени файлов не используются спецификаторы % , то для избежания переполнения диска, следует использовать утилиты для ротации журнальных файлов. В версиях до 8.4, при отсутствии спецификаторов % , PostgreSQL автоматически добавлял время в формате Epoch к имени файла. Сейчас в этом больше нет необходимости.

Если в log_destination включён вывод в формате CSV, то к имени журнального файла будет добавлено расширение .csv . (Если log_filename заканчивается на .log , то это расширение заменится на .csv .)

Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_file_mode ( integer )

В системах Unix задаёт права доступа к журнальным файлам, при включённом logging_collector . (В Windows этот параметр игнорируется.) Значение параметра должно быть числовым, в формате команд chmod и umask . (Для восьмеричного формата, требуется задать лидирующий 0 (ноль).)

Права доступа по умолчанию 0600 , т. е. только владелец сервера может читать и писать в журнальные файлы. Также, может быть полезным значение 0640 , разрешающее чтение файлов членам группы. Однако чтобы установить такое значение, нужно каталог для хранения журнальных файлов (log_directory) вынести за пределы каталога данных кластера. В любом случае нежелательно открывать для всех доступ на чтение журнальных файлов, так как они могут содержать конфиденциальные данные.

Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_rotation_age ( integer )

Определяет максимальное время жизни отдельного журнального файла, при включённом logging_collector . После того как прошло заданное количество минут, создаётся новый журнальный файл. Для запрета создания нового файла по прошествии определённого времени, нужно установить значение 0. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. log_rotation_size ( integer )

Определяет максимальный размер отдельного журнального файла, при включённом logging_collector . После того как заданное количество килобайт записано в текущий файл, создаётся новый журнальный файл. Для запрета создания нового файла при превышении определённого размера, нужно установить значение 0. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_truncate_on_rotation ( boolean )

Если параметр logging_collector включён, PostgreSQL будет перезаписывать существующие журнальные файлы, а не дописывать в них. Однако перезапись при переключении на новый файл возможна только в результате ротации по времени, но не при старте сервера или ротации по размеру файла. При выключенном параметре всегда продолжается запись в существующий файл. Например, включение этого параметра в комбинации с log_filename равным postgresql-%H.log , приведёт к генерации 24-х часовых журнальных файлов, которые циклически перезаписываются. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.

Пример: для хранения журнальных файлов в течение 7 дней, по одному файлу на каждый день с именами вида server_log.Mon , server_log.Tue и т. д., а также с автоматической перезаписью файлов прошлой недели, нужно установить log_filename в server_log.%a , log_truncate_on_rotation в on и log_rotation_age в 1440 .

Пример: для хранения журнальных файлов в течение 24 часов, по одному файлу на час, с дополнительной возможностью переключения файла при превышения 1ГБ, установите log_filename в server_log.%H%M , log_truncate_on_rotation в on , log_rotation_age в 60 и log_rotation_size в 1000000 . Добавление %M в log_filename позволит при переключении по размеру указать другое имя файла в пределах одного часа. syslog_facility ( enum )

При включённом протоколировании в syslog , этот параметр определяет значение « facility » . Допустимые значения LOCAL0 , LOCAL1 , LOCAL2 , LOCAL3 , LOCAL4 , LOCAL5 , LOCAL6 , LOCAL7 . По умолчанию используется LOCAL0 . Подробнее в документации на системный демон syslog . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. syslog_ident ( string )

При включённом протоколировании в syslog , этот параметр задаёт имя программы, которое будет использоваться в syslog для идентификации сообщений относящихся к PostgreSQL . По умолчанию используется postgres . Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. syslog_sequence_numbers ( boolean )

Когда сообщения выводятся в syslog и этот параметр включён (по умолчанию), все сообщения будут предваряться последовательно увеличивающимися номерами (например, [2] ). Это позволяет обойти подавление повторов « — последнее сообщение повторилось N раз — » , которое по умолчанию осуществляется во многих реализациях syslog. В более современных реализациях syslog подавление повторных сообщений можно настроить (например, в rsyslog есть директива $RepeatedMsgReduction ), так что это может излишне. Если же вы действительно хотите, чтобы повторные сообщения подавлялись, вы можете отключить этот параметр.

Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. syslog_split_messages ( boolean )

Когда активен вывод сообщений в syslog , этот параметр определяет, как будут доставляться сообщения. Если он включён (по умолчанию), сообщения разделяются по строкам, а длинные строки разбиваются на строки не длиннее 1024 байт, что составляет типичное ограничение размера для традиционных реализаций syslog. Когда он отключён, сообщения сервера PostgreSQL передаются службе syslog как есть, и она должна сама корректно воспринять потенциально длинные сообщения.

Если syslog в итоге выводит сообщения в текстовый файл, результат будет тем же и лучше оставить этот параметр включённым, так как многие реализации syslog не способны обрабатывать большие сообщения или их нужно специально настраивать для этого. Но если syslog направляет сообщения в некоторую другую среду, может потребоваться или будет удобнее сохранять логическую целостность сообщений.

Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. event_source ( string )

При включённом протоколировании в event log , этот параметр задаёт имя программы, которое будет использоваться в журнале событий для идентификации сообщений относящихся к PostgreSQL . По умолчанию используется PostgreSQL . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.

19.8.2. Когда протоколировать

Управляет минимальным уровнем сообщений, записываемых в журнал сервера. Допустимые значения DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , INFO , NOTICE , WARNING , ERROR , LOG , FATAL и PANIC . Каждый из перечисленных уровней включает все идущие после него. Чем дальше в этом списке уровень сообщения, тем меньше сообщений будет записано в журнал сервера. По умолчанию используется WARNING . Обратите внимание, позиция LOG здесь отличается от принятой в client_min_messages. Только суперпользователи могут изменить этот параметр. log_min_error_statement ( enum )

Управляет тем, какие SQL-операторы, завершившиеся ошибкой, записываются в журнал сервера. SQL-оператор будет записан в журнал, если он завершится ошибкой с указанным уровнем важности или выше. Допустимые значения: DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , INFO , NOTICE , WARNING , ERROR , LOG , FATAL и PANIC . По умолчанию используется ERROR . Это означает, что в журнал сервера будут записаны все операторы, завершившиеся сообщением с уровнем важности ERROR , LOG , FATAL и PANIC . Чтобы фактически отключить запись операторов с ошибками, установите для этого параметра значение PANIC . Изменить этот параметр могут только суперпользователи. log_min_duration_statement ( integer )

Записывает в журнал продолжительность выполнения всех команд, время работы которых равно или превышает указанное количество миллисекунд. Значение 0 (ноль) заставляет записывать продолжительность работы всех команд. Значение -1 (по умолчанию) запрещает регистрировать продолжительность выполнения операторов. Например, при значении 250ms , все команды, которые выполняются за 250 миллисекунд и дольше будут записаны в журнал сервера. Включение параметра полезно для выявления плохо оптимизированных запросов в приложении. Только суперпользователи могут изменить этот параметр.

Для клиентов, использующих расширенный протокол запросов, будет записываться продолжительность фаз: разбор, связывание и выполнение.


При использовании совместно с log_statement, текст SQL-операторов будет записываться только один раз (от использования log_statement ) и не будет задублирован в сообщении о длительности выполнения. Если не используется вывод в syslog , то рекомендуется в log_line_prefix включить идентификатор процесса или сессии. Это позволит связать текст запроса с записью о продолжительности выполнения, которая появится позже.

В Таблице 19.2 поясняются уровни важности сообщений в PostgreSQL . Также в этой таблице показано, как эти уровни транслируются в системные при использовании syslog или eventlog в Windows.

Таблица 19.2. Уровни важности сообщений

Уровень Использование syslog eventlog
DEBUG1..DEBUG5 Более детальная информация для разработчиков. Чем больше номер, тем детальнее. DEBUG INFORMATION
INFO Неявно запрошенная пользователем информация, например вывод команды VACUUM VERBOSE . INFO INFORMATION
NOTICE Информация, которая может быть полезной пользователям. Например, уведомления об усечении длинных идентификаторов. NOTICE INFORMATION
WARNING Предупреждения о возможных проблемах. Например, COMMIT вне транзакционного блока. NOTICE WARNING
ERROR Сообщает об ошибке, из-за которой прервана текущая команда. WARNING ERROR
LOG Информация, полезная для администраторов. Например, выполнение контрольных точек. INFO INFORMATION
FATAL Сообщает об ошибке, из-за которой прервана текущая сессия. ERR ERROR
PANIC Сообщает об ошибке, из-за которой прерваны все сессии. CRIT ERROR

19.8.3. Что протоколировать

application_name это любая строка, не превышающая NAMEDATALEN символов (64 символа при стандартной сборке). Обычно устанавливается приложением при подключении к серверу. Значение отображается в представлении pg_stat_activity и добавляется в журнал сервера, при использовании формата CSV. Для прочих форматов, application_name можно добавить в журнал через параметр log_line_prefix. Значение application_name может содержать только печатные ASCII символы. Остальные символы будут заменены знаками вопроса ( ? ). debug_print_parse ( boolean )
debug_print_rewritten ( boolean )
debug_print_plan ( boolean )

Эти параметры включают вывод различной отладочной информации. А именно: вывод дерева запроса, дерево запроса после применения правил или плана выполнения запроса, соответственно. Все эти сообщения имеют уровень LOG . Поэтому, по умолчанию, они записываются в журнал сервера, но не отправляются клиенту. Отправку клиенту можно настроить через client_min_messages и/или log_min_messages. По умолчанию параметры выключены. debug_pretty_print ( boolean )

Включает выравнивание сообщений, выводимых debug_print_parse , debug_print_rewritten или debug_print_plan . В результате сообщения легче читать, но они значительно длиннее, чем в формате « compact » , который используется при выключенном значении. По умолчанию включён. log_checkpoints ( boolean )

Включает протоколирование выполнения контрольных точек и точек перезапуска сервера. При этом записывается некоторая статистическая информация. Например, число записанных буферов и время, затраченное на их запись. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. По умолчанию выключен. log_connections ( boolean )

Включает протоколирование всех попыток подключения к серверу, в том числе успешного завершения аутентификации клиентов. Изменить его можно только в начале сеанса и сделать это могут только суперпользователи. Значение по умолчанию — off .


Некоторые программы, например psql , предпринимают две попытки подключения (первая для определения, нужен ли пароль). Поэтому дублирование сообщения « connection received » не обязательно говорит о наличии проблемы.

Включает протоколирование завершения сеанса. В журнал выводится примерно та же информация, что и с log_connections , плюс длительность сеанса. Изменить этот параметр можно только в начале сеанса и сделать это могут только суперпользователи. Значение по умолчанию — off . log_duration ( boolean )

Записывает продолжительность каждой завершённой команды. По умолчанию выключен. Только суперпользователи могут изменить этот параметр.

Для клиентов, использующих расширенный протокол запросов, будет записываться продолжительность фаз: разбор, связывание и выполнение.


Включение этого параметра не равнозначно установке нулевого значения для log_min_duration_statement. Разница в том, что при превышении значения log_min_duration_statement в журнал записывается текст запроса, а при включении данного параметра — нет. Таким образом при log_duration = on и положительном значении log_min_duration_statement в журнал записывается длительность всех команд, а текст запросов — только для команд с длительностью, превысившей предел. Такое поведение может оказаться полезным при сборе статистики в условиях большой нагрузки.

Управляет количеством детальной информации, записываемой в журнал сервера для каждого сообщения. Допустимые значения: TERSE , DEFAULT и VERBOSE . Каждое последующее значение добавляет больше полей в выводимое сообщение. Для TERSE из сообщения об ошибке исключаются поля DETAIL , HINT , QUERY и CONTEXT . Для VERBOSE в сообщение включается код ошибки SQLSTATE (см. Приложение A), а также имя файла с исходным кодом, имя функции и номер строки сгенерировавшей ошибку. Только суперпользователи могут изменить этот параметр. log_hostname ( boolean )

По умолчанию, сообщения журнала содержат лишь IP-адрес подключившегося клиента. При включении этого параметра, дополнительно будет фиксироваться и имя сервера. Обратите внимание, что в зависимости от применяемого способа разрешения имён, это может отрицательно сказаться на производительности. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_line_prefix ( string )

Строка, в стиле функции printf , которая выводится в начале каждой строки журнала сообщений. С символов % начинаются управляющие последовательности, которые заменяются статусной информацией, описанной ниже. Неизвестные управляющие последовательности игнорируются. Все остальные символы напрямую копируются в выводимую строку. Некоторые управляющие последовательности используются только для пользовательских процессов и будут игнорироваться фоновыми процессами, например основным процессом сервера. Статусная информация может быть выровнена по ширине влево или вправо указанием числа после % и перед кодом последовательности. Отрицательное число дополняет значение пробелами справа до заданной ширины, а положительное число — слева. Выравнивание может быть полезно для улучшения читаемости. Этот параметр можно задать только в файле postgresql.conf или в командной строке при запуске сервера. Со значением по умолчанию, ‘%m [%p] ‘ , в журнал выводится метка времени и идентификатор процесса.

Спецсимвол Назначение Только для пользовательского процесса
%a Имя приложения (application_name) да
%u Имя пользователя да
%d Имя базы данных да
%r Имя удалённого узла или IP-адрес, а также номер порта да
%h Имя удалённого узла или IP-адрес да
%p Идентификатор процесса нет
%t Штамп времени, без миллисекунд нет
%m Штамп времени, с миллисекундами нет
%n Штамп времени, с миллисекундами (в виде времени Unix) нет
%i Тег команды: тип текущей команды в сессии да
%e Код ошибки SQLSTATE нет
%c Идентификатор сессии. Подробности ниже нет
%l Номер строки журнала для каждой сессии или процесса. Начинается с 1 нет
%s Штамп времени начала процесса нет
%v Идентификатор виртуальной транзакции (backendID/localXID) нет
%x Идентификатор транзакции (0 если не присвоен) нет
%q Ничего не выводит. Непользовательские процессы останавливаются в этой точке. Игнорируется пользовательскими процессами нет
%% Выводит % нет

%c выводит псевдоуникальный номер сеанса, состоящий из двух 4-байтных шестнадцатеричных чисел (без ведущих нулей), разделённых точкой. Эти числа представляют время старта процесса и идентификатор процесса, поэтому %c можно использовать для экономии места при выводе этих значений. Например, для получения идентификатора сеанса из pg_stat_activity используйте запрос:


Последним символом в log_line_prefix лучше оставлять пробел, чтобы отделить от остальной строки. Можно использовать и символы пунктуации.


Syslog также формирует штамп времени и идентификатор процесса, поэтому вероятно нет смысла использовать соответствующие управляющие последовательности при использовании syslog .


Спецпоследовательность %q полезна для включения информации, которая существует только в контексте сеанса (обслуживающего процесса), например, имя пользователя или базы данных. Например:

Определяет, нужно ли фиксировать в журнале события, когда сеанс ожидает получения блокировки дольше, чем указано в deadlock_timeout. Это позволяет выяснить, не связана ли низкая производительность с ожиданием блокировок. По умолчанию отключено. Только суперпользователи могут изменить этот параметр. log_statement ( enum )

Управляет тем, какие SQL-команды записывать в журнал. Допустимые значения: none (отключено), ddl , mod и all (все команды). ddl записывает все команды определения данных, такие как CREATE , ALTER , DROP . mod записывает все команды ddl , а также команды изменяющие данные, такие как INSERT , UPDATE , DELETE , TRUNCATE и COPY FROM . PREPARE , EXECUTE и EXPLAIN ANALYZE также записываются, если вызваны для команды соответствующего типа. Если клиент использует расширенный протокол запросов, то запись происходит на фазе выполнения и содержит значения всех связанных переменных (если есть символы одиночных кавычек, то они дублируются).

По умолчанию none . Только суперпользователи могут изменить этот параметр.


Команды с синтаксическими ошибками не записываются, даже если log_statement = all , так как сообщение формируется только после выполнения предварительного разбора, определяющего тип команды. При расширенном протоколе запросов, похожим образом не будут записываться команды, неуспешно завершившиеся до фазы выполнения (например, при разборе или построении плана запроса). Для включения в журнал таких команд установите log_min_error_statement в ERROR (или ниже).

Включает запись в журнал сервера всех команд репликации. Подробнее о командах репликации можно узнать в Разделе 53.4. Значение по умолчанию — off . Изменить этот параметр могут только суперпользователи. log_temp_files ( integer )

Управляет включением в журнал информации об именах и размерах временных файлов. Временные файлы могут использоваться для сортировок, хеширования и временного хранения результатов запросов. На каждый временный файл, при его удалении, в журнал записывается отдельное сообщение. Значение 0 говорит о том, что нужно записывать информацию о всех временных файлах. Положительное значение задаёт размер временных файлов в килобайтах, при достижении или превышении которого, информация о временном файле будет записана. Значение по умолчанию -1, что отключает запись информации о временных файлах. Только суперпользователи могут изменить этот параметр. log_timezone ( string )

Устанавливает часовой пояс для штампов времени при записи в журнал сервера. В отличие от TimeZone, это значение одинаково для всех баз данных кластера, поэтому для всех сессий используются согласованные значения штампов времени. Встроенное значение по умолчанию GMT , но оно переопределяется в postgresql.conf : initdb записывает в него значение, соответствующее системной среде. Подробнее об этом в Подразделе 8.5.3. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.

19.8.4. Использование вывода журнала в формате CSV

Добавление csvlog в log_destination делает удобным загрузку журнальных файлов в таблицу базы данных. Строки журнала представляют собой значения разделённые запятыми (CSV формат) со следующими полями: штамп времени с миллисекундами; имя пользователя; имя базы данных; идентификатор процесса; клиентский узел:номер порта; идентификатор сессии; номер строки каждой сессии; тег команды; время начала сессии; виртуальный идентификатор транзакции; идентификатор транзакции; уровень важности ошибки; код ошибки SQLSTATE; сообщение об ошибке; подробности к сообщению об ошибке; подсказка к сообщению об ошибке; внутренний запрос, приведший к ошибке (если есть); номер символа внутреннего запроса, где произошла ошибка; контекст ошибки; запрос пользователя, приведший к ошибке (если есть и включён log_min_error_statement ); номер символа в запросе пользователя, где произошла ошибка; расположение ошибки в исходном коде PostgreSQL (если log_error_verbosity установлен в verbose ) и имя приложения. Вот пример определения таблицы, для хранения журналов в формате CSV:

Для загрузки журнального файла в такую таблицу можно использовать команду COPY FROM :

Также можно обратиться к этому файлу как к сторонней таблице, используя поставляемый модуль file_fdw.

Для упрощения загрузки журналов в CSV формате используйте следующее:

Установите для log_filename и log_rotation_age значения, гарантирующие согласованную и предсказуемую схему именования журнальных файлов. Зная, какие имена будут у журнальных файлов, можно определить, когда конкретный файл заполнен и готов к загрузке.

Установите log_rotation_size в 0, чтобы запретить ротацию файлов по достижении определённого размера, так как это делает непредсказуемой схему именования журнальных файлов.

Установите log_truncate_on_rotation в on , чтобы новые сообщения не смешивались со старыми при переключении на существующий файл.

Определение таблицы содержит первичный ключ. Это полезно для предотвращения случайной повторной загрузки данных. Команда COPY фиксирует изменения один раз, поэтому любая ошибка приведёт к отмене всей загрузки. Если сначала загрузить неполный журнальный файл, то его повторная загрузка (по заполнении) приведёт к нарушению первичного ключа и, следовательно, к ошибке загрузки. Поэтому необходимо дожидаться окончания записи в журнальный файл перед началом загрузки. Похожим образом предотвращается случайная загрузка частично сформированной строки сообщения, что также приведёт к сбою в команде COPY .

19.8.5. Заголовок процесса

Эти параметры влияют на то, как формируются заголовки серверных процессов. Заголовок процесса обычно можно наблюдать в программах типа ps , а в Windows — в Process Explorer . За подробностями обратитесь к Разделу 28.1.

Задаёт имя кластера, которое отображается в заголовке процесса для всех серверных процессов данного кластера. Это имя может быть любой строкой не длиннее NAMEDATALEN символов (64 символа в стандартной сборке). В строке cluster_name могут использоваться только печатаемые ASCII-символы. Любой другой символ будет заменён символом вопроса ( ? ). Если этот параметр содержит пустую строку » (это значение по умолчанию), никакое имя не выводится. Этот параметр можно задать только при запуске сервера. update_process_title ( boolean )

Включает изменение заголовка процесса при получении сервером каждой очередной команды SQL. На большинстве платформ он включён (имеет значение on ), но в Windows по умолчанию выключен ( off ) ввиду больших издержек на изменение этого заголовка. Изменить этот параметр могут только суперпользователи.


You may also like...