39.1. Обзор механизма работы триггеров событий
Триггер события срабатывает всякий раз, когда в базе данных, в которой он определён, происходит связанное с ним событие. В настоящий момент поддерживаются следующие события: ddl_command_start
, ddl_command_end
, table_rewrite
и sql_drop
. Поддержка дополнительных событий может быть добавлена в будущих выпусках.
Событие ddl_command_start
происходит непосредственно перед выполнением команд CREATE
, ALTER
, DROP
, SECURITY LABEL
, COMMENT
, GRANT
и REVOKE
. Проверка на существование объекта перед срабатыванием триггера не производится. В качестве исключения, однако, это событие не происходит для команд DDL, обращающихся к общим объектам кластера базы данных — базам данных, табличным пространствам, ролям, а также к самим триггерам событий. Событие ddl_command_start
также происходит непосредственно перед выполнением команды SELECT INTO
, так как она равнозначна команде CREATE TABLE AS
.
Событие ddl_command_end
происходит непосредственно после выполнения команд из того же набора. Чтобы получить дополнительную информацию об операциях DDL, повлёкших произошедшее событие, вызовите функцию pg_event_trigger_ddl_commands()
, возвращающую множество, из кода обработчика события ddl_command_end
(см. Раздел 9.29). Заметьте, что этот триггер срабатывает после того, как эти действия имели место (но до фиксации транзакции), так что в системных каталогах можно увидеть уже изменённое состояние.
Событие sql_drop
происходит непосредственно перед событием ddl_command_end
для команд, которые удаляют объекты базы данных. Для получения списка удалённых объектов используйте возвращающую набор строк функцию pg_event_trigger_dropped_objects()
в триггере события sql_drop
(см. Раздел 9.29). Обратите внимание, что триггер выполняется после удаления объектов из таблиц системного каталога, поэтому их невозможно больше увидеть.
Событие table_rewrite
происходит непосредственно перед тем, как таблица будет перезаписана в результате определённых действий команд ALTER TABLE
и ALTER TYPE
. Хотя перезапись таблицы может быть вызвана и другими управляющими операторами, в частности CLUSTER
и VACUUM
, событие table_rewrite
для них не вызывается. Найти OID таблицы, которая была перезаписана, можно с помощью функции pg_event_trigger_table_rewrite_oid()
(см. Раздел 9.29). Причину (причины) перезаписи можно посмотреть с помощью функции pg_event_trigger_table_rewrite_reason()
.
Триггеры событий (как и прочие функции) не могут выполняться в прерванной транзакции. Поэтому, если команда DDL завершается ошибкой, соответствующие триггеры ddl_command_end
не сработают. И наоборот, если триггер ddl_command_end
завершился с ошибкой, последующие триггеры событий не сработают, так же как и сама команда не будет выполняться. Похожим образом, если триггер ddl_command_end
завершится ошибкой, действие команды DDL будет отменено, как это происходит при возникновении ошибки внутри транзакции.
Полный список команд, которые поддерживаются триггерами событий, можно найти в Разделе 39.2.
Для создания триггера события используется команда CREATE EVENT TRIGGER. Предварительно нужно создать функцию, со специальным возвращаемым типом event_trigger
. Данная функция не обязана возвращать значение (и может не возвращать). Возвращаемый тип служит лишь указанием на то, что функция будет вызываться из триггера события.
Если есть несколько триггеров на одно и то же событие, то они будут вызываться в алфавитном порядке по имени триггера.
В определении триггера можно использовать условие WHEN
, чтобы, например, триггер ddl_command_start
срабатывал только для отдельных команд, которые нужно перехватить. Триггеры событий часто используются для ограничения диапазона DDL-команд, доступных пользователям.
18.9. Run-time Statistics
18.9.1. Query and Index Statistics Collector
These parameters control server-wide statistics collection features. When statistics collection is enabled, the data that is produced can be accessed via the pg_stat
and pg_statio
family of system views. Refer to Chapter 27 for more information.
track_activities
(boolean
)Enables the collection of information on the currently executing command of each session, along with the time when that command began execution. This parameter is on by default. Note that even when enabled, this information is not visible to all users, only to superusers, roles with privileges of the
pg_read_all_stats
role and the user owning the sessions being reported on (including sessions belonging to a role they have the privileges of), so it should not represent a security risk. Only superusers can change this setting.track_activity_query_size
(integer
)Specifies the number of bytes reserved to track the currently executing command for each active session, for the
pg_stat_activity
.query
field. The default value is 1024. This parameter can only be set at server start.track_counts
(boolean
)Enables collection of statistics on database activity. This parameter is on by default, because the autovacuum daemon needs the collected information. Only superusers can change this setting.
track_io_timing
(boolean
)Enables timing of database I/O calls. This parameter is off by default, because it will repeatedly query the operating system for the current time, which may cause significant overhead on some platforms. You can use the pg_test_timing tool to measure the overhead of timing on your system. I/O timing information is displayed in pg_stat_database, in the output of EXPLAIN when the
BUFFERS
option is used, and by pg_stat_statements. Only superusers can change this setting.track_functions
(enum
)Enables tracking of function call counts and time used. Specify
pl
to track only procedural-language functions,all
to also track SQL and C language functions. The default isnone
, which disables function statistics tracking. Only superusers can change this setting.Note
SQL-language functions that are simple enough to be “inlined” into the calling query will not be tracked, regardless of this setting.
stats_temp_directory
(string
)Sets the directory to store temporary statistics data in. This can be a path relative to the data directory or an absolute path. The default is
pg_stat_tmp
. Pointing this at a RAM-based file system will decrease physical I/O requirements and can lead to improved performance. This parameter can only be set in thepostgresql.conf
file or on the server command line.
18.9.2. Statistics Monitoring
log_statement_stats
(boolean
)log_parser_stats
(boolean
)log_planner_stats
(boolean
)log_executor_stats
(boolean
)For each query, output performance statistics of the respective module to the server log. This is a crude profiling instrument, similar to the Unix
getrusage()
operating system facility.log_statement_stats
reports total statement statistics, while the others report per-module statistics.log_statement_stats
cannot be enabled together with any of the per-module options. All of these options are disabled by default. Only superusers can change these settings.