Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Розділ 18. Налаштування сервера.
Є багато параметрів налаштування, що впливають на роботу системи баз даних. В першому підрозділі, ми опишемо, як встановлювати параметри, а в наступних обговоримо кожен з них в подробицях.
18.1. Задання параметрів.
Всі імена параметрів є чутливими до регістру. Кожен параметр має значення одного з 5 типів: булеве, ціле, з плаваючою комою, рядок, або перелік. Булеві величини, можуть задаватись як on, off, true, false, yes, no, 1, 0 (не чутливі до регістру, або будь-яка модифікація їх.
Деякі значення задають пам'ять, або значення часу. Кожен з них має неявну одиницю вимірювання, наприклад кілобайти, блоки, мілісекунди, секунди, хвилини. По замовчуванню вони задані в pg_settings.unit. Для зручності, кожна одиниця вимірювання може задаватись явно. Правильні одиниці памяті – це kB(kilobytes), MB(megabytes), andGB(gigabytes); значення часу задаються в ms (milliseconds), s (seconds), min (minutes), h (hours), and d (days). Зауважте, що множник для одиниць часу є 1024, а не 1000.
Параметри типу «перелік» задаються так само, як рядкові параметри, але обмежуються набором значень. Дозволені значення можна знайти в pg_settings.enumvals. Вони нечутливі до регістру.
Одним із способів задавання цих параметрів є редагування файлу postgresql.conf, який зберігається в каталозі даних (копія по замовчуванню встановлюється при ініціюванні каталога кластера бази даних). Приклад того, як цей файл має виглядати:
# This is a comment
log_connections = yes
log_destination = ’syslog’
search_path = ’"$user", public’
shared_buffers = 128MB
В одному рядку задається один праметр. Знак рівності не є необхідним між іменем та значенням. Пробіли і пусті рядки ігноруються. Позначка # перетворює решту рядка в коментар. Значення параметрів, що не є ідентифікаторами чи цифрами, беруться в апостроф. Щоб включити апостроф в значення, вводьте дві лапки, або зворотній апостроф.
В додаток до властивостей, файл postgresql.conf може містити директиви include, які задають інший файл для читання. Таке обявлення виглядає наступним чином:
include ’filename’
Якщо назва файлу не є абсолютнм шляхом, він буде шукатись у папці з поточним файлом конфігурації. Включення можуть бути багаторівневими.
Файл конфігурації перечитується коли головний процес серверу отримує сигнал SIGHUP, який відсилається через pg_ctl reload. Головний процес передає цей сигнал всім іншим серверним процесам, тож вони теж отримають нові значення. Ви також можете послати сигнал серверу напряму. Деякі параметри можуть задаватись тільки при запуску сервера, зміни в них будуть ігноруватись до перезапуску сервера.
Другим шляхом встановити ці параметри є надання їх як опції в командному рядку до команди postgres, наприклад postgres
-c log_connections=yes -c log_destination=’syslog’
Ці опції перевизначають конфліктуючі переметри в postgresql.conf. Зауважте, що це означає, що ви на зможете змінити значення на ходу зміною postgresql.conf., тому це може коштувати вам гнучкості.
Деколи корисно задавати опцію тільки одній сесії. Змінна середовища PGOPTIONS для цього використовується з клієнтського боку:
env PGOPTIONS=’-c geqo=off’ psql
Це працює з клієнтськими додатками libpq, а не тільки з psql. Зауважте, що це не буде працювати для параметрів, що фіксуються при запуску сервера, або мають задаватись у postgresql.conf.
Можливо присвоювати значення параметра для користувача або бази даних. Коли стартує робота, завантажуються значення по замовчуванню для користувача та бази даних. Команди ALTER USER та ALTER DATABASE використовуються для конфігурації цих опцій. Опції бази даних перевизначають все отримане від командного рядка postgres або файлу конфігурації, і перевизначаються налаштуваннями користувача, котрі в свою чергу перевизначаються налаштуваннями сесії.
Деякі параметри можуть мінятись в окремих сесіях SQL командою SET, для прикладу:
SET ENABLE_SEQSCAN TO OFF;
Якщо дозволений SET, він перевизначає всі інші джерела і значення параметрів. Деякі параметри не можуть мінятись через SET, для прикладу, якщо вони контролюють поведінку, яка не змінюється без перезавантаження сервера. Також, деякі модифікації параметрів SET або ALTER вимагають прав суперкористувача.
Команда SHOW дозволяє перевірку всіх поточних значень та параметрів.
Віртуальна таблиця pg_settings, описана в розділі 45.55 також дозволяє вивід і оновлення параметрів роботи. Вона еквівалентна SHOW і SET, але може бути більш зручною для використання, оскільки може приєднуватись з іншими таблицями, або умовами. Вони також містить більше інформації про дозволені значення параметрів.
18.2. Розміщення файлів.
В додаток до postgresql.conf, PostgreSQL використовує ще два файли, які можна редагувати, які контролюють аутентифікацію клієнта (використання описане в розділі 19). По замовчуванню, всі три файли конфігурації зберігаються в одному кластері бази даних. Параметри, описані в цьому розділі дозволяють цим файлам розміщуватись де-небудь. (це спрощує адміністрування, адже так простіше перевіряти, чи відновились файли, якщо вони зберігаються окремо).
data_directory (string)
Задає каталог для зберігання даних. Задається при запуску сервера.
config_file (string)
Задає головний файл конфігурації сервера. Цей параметр установлюється з командного рядка postgres.
hba_file (string)
Задає файл конфігурації для аутентифікації на хості (pg_hba.conf). Задається при запуску сервера.
ident_file (string)
Задає файл конфігурації для управління користувачами (pg_ident.conf). Задається при запуску сервера.
external_pid_file (string)
Задає імя додаткового файлу pid, який має створити сервер для використання програм адміністрування. Задається при запуску сервера.
В інсталяції по замовчуванню, жоден з цих параметрів не задається явно. Натомість, каталог даних задається опцією –D або змінною середовища PGDATA, а файли конфігурацій шукаються в каталозі даних.
Якщо ви хочете зберігати файли конфігурацій поза каталогом даних, опція postgres –D або змінна PGDATA, мають вказувати на потрібний каталог, а параметр data_directory має задаватись в postgresql.conf, щоб показати, де розміщуються дані. Зауважте, що data_directory перевизначає -D і PGDATA для значень каталога даних, але не для файлів конфігурації.
Якщо ви хочете, ви можете задати назви файлів конфігурації та їх розміщення, використовуючи параметри config_file, hba_file і/або ident_file. config_file, які задаються з командного рядка, а інші задаються всередині основного файлу конфігурації. Якщо всі три параметри плюс data_directory задані явно, тоді непотрібно задавати –D або PGDATA.
Коли встановлюєте ці параметри, відносний шлях буде вираховуватись відносно каталога, в якому запущений postgres.
18.3. Зєднання і аутентифікація
18.3.1. Опції зєднання
listen_addresses (string)
задає TCP/IP адреси на яких сервер прослуховує зєднання від клієнтських додатків. Значення приймає форму списку, розділеного комою. В якому містяться імена хостів або цифрові ІР-адреси. Спеціальний символ * відповідає всім доступним ІР-адресам. Якщо список пустий, сервер не прослуховує інтерфейс взагалі, в цьому випадку використовуються сокети домена Unix. Значення по замовчуванню – локалхост, що дозволяє зєднання тільки всередині хоста. Коли аутентифікація специфікує, хто може заходити на сервер, listen_addresses контролює інтерфейси, що встановлюють зєднання, що допомагає запобігати повторюваним небажаним запитам зєднання в незахищених мережах. Цей параметр задається при запуску сервера.
port (integer)
Порт ТСР, що прослуховується сервером, 5432 по замовчуванню. Зауважте, що цей же порт використовується для прослуховування ІР-адрем. Цей параметр задається при запуску сервера.
max_connections (integer)
визначає максимальну кількість зєднань до сервера бази даних. Значення по замовчуванню – 100, але воно може бути меншим, якщо ваші налаштування ядра не підтримує таку кількість. Задається при запуску сервера.
Збільшення цього значення, причитить запит більше памяті загального доступу і семафорів, ніж підтримує ваша система. Дивіться розділ 17.4.1, щоб співставити параметри.
Коли запускаєте похідний сервер, маєте задати це значення з таким же, або вищим значенням, ніж на основному сервері. Інакше на вашому сервері не будуть дозволені запити.
superuser_reserved_connections (integer)
Визначає кількість зєднань для суперкористувачів PostgreSQL. В більшості зєднань може бути активним тимчасово. Коли кількість активних зєднань рівна різниці між max_connections та superuser_reserved_connections, нові зєднання дозволяються тільки суперкористувачам.
Значення по замовчуванню – три зєднання. Значення мусить бути меншим, ніж max_connections. Цей параметр задається при запуску сервера.
unix_socket_directory (string)
Задає каталог сокета домена Unix, на якому сервер буде прослуховувати зєднання клієнтських додатків. По замовчуванню це /tmp, але його можна міняти під час побудови. Цей параметр задається при запуску сервера.
unix_socket_group (string)
Задає групу власників сокета домена Unix (це завжди користувач, що запускає сервер). В поєднанні з unix_socket_permissions використовується для додаткового контролю доступу до цього типу зєднань. По замовчуванню, це пустий рядок, який використовує групу по замовчуванню для користувача сервера. Задається при запуску сервера.
unix_socket_permissions (integer)
Задає дозволи доступу до сокета. Це набір типових значень доступу до файлової системи Unix. Значення параметра має бути числом, заданим в форматі, прийнятному для системних викликів chmod і umask (вісімковий формат, якщо число починається з 0).
По замовчуванню дозвіл 0777, що дозволяє зєднуватись всім. Альтернативними є 0770 (тільки для користувача і групи), і 0700 (тільки для користувача). Зауважте, що значення мають тільки зопції запису, нема смислу в задаванні читання чи виконання.
Цей механізм контролю доступу незалежний від описаного в розділі 19. Задається при запуску сервера.
bonjour (boolean)
Задає повідомлення про існування сервера черещ Bonjour. По замуовчуванню виключений. Задається при запуску сервера.
bonjour_name (string)
задає імя служби Bonjour. Використовується імя компютера, якщо параметром є пустий рядок. Цей параметр ігнорується якщо не встановлена підтримка Bonjour. Задається при запуску сервера.
tcp_keepalives_idle (integer)
На системах, що підтримують опцію сокета TCP_KEEPIDLE, задає число секунд між посиланнями keepalives. Значення 0 використовується по замовчуванню. Якщо TCP_KEEPIDLE не підтримується, параметр має бути рівним 0. Цей параметр ігнорується зєднаннями сокета домена Unix.
tcp_keepalives_interval (integer)
На системах, що підтримують опцію сокета TCP_KEEPIDLE, задає скільки чекати на відповідь на keepalive перед перепосиланням. Значення 0 використовується по замовчуванню. Якщо TCP_KEEPIDLE не підтримується, параметр має бути рівним 0. Цей параметр ігнорується зєднаннями сокета домена Unix.
tcp_keepalives_count (integer)
На системах, що підтримують опцію сокета TCP_KEEPIDLE, задаєкількість спроб keepalive, перед тим, як визнати зєднання мертвим. Значення 0 використовується по замовчуванню. Якщо TCP_KEEPIDLE не підтримується, параметр має бути рівним 0. Цей параметр ігнорується зєднаннями сокета домена Unix.
18.3.2. Захист і аутиентифікація
authentication_timeout (integer)
Максимальний час для виконання аутентифікації, в секундах. Якщо клієнт не здійснив аутенфифікацію за цей час, сервер закриває зєднання. Це запобігає зависшим клієнтам займати зєднання. По замовчуванню це 1 хвилина. Цей параметр задається через файл postgresql.conf або командний рядок сервера.
ssl (boolean)
Включає зєднання SSL. Дивіться розділ 17.8. По замовчуванню вимкнене. Цей параметр задається при запуску сервера. Зєднання SSL можливе тільки через TCP/IP
ssl_renegotiation_limit (integer)
Задає скільки даних може йти через шифроване зєднання перед тим, як змінити ключі сесії. Зміна зменшує шанси хакерів провести криптоаналіз великих обємів трафіку і але вона затримує виконання. Сума отриманого і відправленого трафіку складає ліміт. Якщо параметр рівний 0, зміна ключів відключена. По замовчуванню 512 Мб.
Зауваження: бібліотеки SSL до листопада 2009 не захищені при використанні зміни ключів, через уразливість протоколу SSL. Як короткочасне вирішення, було вирішено відключити зміну ключів. Якщо є такі бібліотеки на сервері чи клієнті, зміна ключів має бути виключена.
ssl_ciphers (string)
Задає список шифрів, які дозволені для шифрування зєднань. Перегляньте документацію openssl.
password_encryption (boolean)
Якщо пароль заданий в CREATE USER або ALTER USER без параметру ENCRYPTED або UNENCRYPTED, цей параметр визначає чи пароль має бути шифрованим. По замовчуванню ввімкнено (пароль шифрується).
krb_server_keyfile (string)
Задає розміщення файла ключа сервера Kerberos. Дивіться 19.3.5 або 19.3.3 для деталей. Цей параметр може задаватись в файлі postgresql.conf або командному рядку сервера.
krb_srvname (string)
задає імя служби Kerberos. Цей параметр може задаватись в файлі postgresql.conf або командному рядку сервера.
krb_caseins_users (boolean)
Задає, чи імена користувачів Kerberos і GSSAPI будуть нечутливими до регістру. По замовчуванню виключене. Цей параметр може задаватись в файлі postgresql.conf або командному рядку сервера.
db_user_namespace (boolean)
Задає імена користувачів бази даних. Вимкнуто за замовчуванням. Цей параметр може задаватись в файлі postgresql.conf або командному рядку сервера.
Якщо він включений ви маєте створювати користувачів як username@dbname. Коли клієнт проходить перевірку, шукається база даних, привязана до нього. Зауважте, що якщо ви створюєте користувача з @ в середовищі SQL, ви маєте брати його в апострофи.
З включеним цим параметром, ви можете створювати і глобальних користувачів. Просто задавайте @ в кінці імені, наприклад joe@. @ буде відкидатись при пошуку імені на сервері.
db_user_namespace спричиняє різницю між представленням імені користувача на клієнті та на сервері. Методи аутентифікації мають відповідати іменам на сервері, а не на клієнті. Оскільки md5 використовує імя на клієнті та на сервері, його не можна використовувати з db_user_namespace.
Зауваження: Ця можливість задана як тимчасове рішення, доки не знайдеться повне вирішення. Тоді цю опцію видалять.
18.4. Споживання ресурсів
18.4.1. Пам'ять.
shared_buffers (integer)
Встановлює обєм памяті, який сервер використовує для буфера памяті загального доступу. По замовчуванню типово 32 Мб, але може бути менше, якщо ваше ядро не підтримує таку кількість. Це значення має бути як мінімум 12 кб (змінити мінімум можна в BLCKSZ). Хоча набагато більші значення потрібні для нормальної роботи. Цей параметр задається при запуску сервера.
Якщо ви маєте сервер з 1 Гб ОЗП або більше, нормальне значення для shared_buffers буде 25% від памяті в системі. Є деякі роботи, де ефективними є навіть більші значення shared_buffers, але оскільки PostgreSQL посилається на кеш операційної системи, швидше за все значення 40% ОЗП не буде працювати швидше. Більші значення shared_buffers вимагають відповідного збільшення checkpoint_segments, для запобігання запису процесом великих обємів нових або змінених даних за довший період часу.
На системах з менше ніж 1 Гб ОЗП, потрібен менший відсоток ОЗП, для того, щоб залишити потрібне місце для системи. Також, на Віндовс, великі значення shared_buffers не є ефективними. Ви можете отримати кращі результати збереженням низьких значень і використаням кешу операційної системи. Хорошим значенням для shared_buffers в Віндовс буде від 64 до 512 Мб.
Збільшення цього параметро призводить до запиту більшої кількості памяті загального доступу та семафорів. Про те, як встановити ці параметри, в Розділі 17.4.1
temp_buffers (integer)
Встановлює максимальну кількість тимчасових буферів, використовуваних сесією бази даних. Це буфери для локальних сесій, для доступу до тимчасових таблиць. По замовчуванню це 8 Мб. Значення може змінюватись в окремих сесіях, але тільки до першого використання тимчасових таблиць, наступні спроби змінити значення не дадуть нічого.
Сесія обмежить тимчасові буфери згідно temp_buffers. Платою встановлення великого значення для сесій, що цього не вимагають, це дескриптор буфера, або біль 64 байтів для кожного збільшення. Але буфер використовує додаткові 8192 байтів для цього (або, в загальному BLCKSZ байтів).
max_prepared_transactions (integer)
Задає максимальне число транзакцій, які можуть бути підготовлені (дивіться PREPARE TRANSACTION). Встановлення цього параметра в 0 (що є по замовчуванню), відключає можливість підготовлених транзакцій. Цей параметр задається при запуску сервера.
Якщо ви не плануєте використовувати її, цей параметр має бути встановлений в 0 для запобігання створення транзакцій. Якщо ви використовуєте транзакції, вам потрібно, щоб max_prepared_transactions був хоча б таки же, як max_connections, тобто кожна сесія мала власний виклик підготовленої транзакції.
Збільшення цього параметро призводить до запиту більшої кількості памяті загального доступу, ніж дозволяє ваша ОС. Про те, як встановити ці параметри, в Розділі 17.4.1.
Коли запускаєте похідний сервер, цей параметр має бути таким же, або перевищувати значення на головному сервері, інакше не будуть дозволені запити.
work_mem (integer)
Задає обєм памяті, що використовується у внутрішніх операціях сортування та хеш-таблицях перед записом в тимчасові файли. Значення по замовчуванню 1 Мб. Зауважте, що для складного запиту має бути декілька сортувань паралельно. Кожна операція дозволить використання такого обєму памяті, яке задає це значення перед стартом запису в тимчасові файли. Також одночасно декілька сесій можуть виконувати цю операцію. Тому загальна пам'ять може бути в декілька разів більшою за значення work_mem; необхідно памятати про це при виборі значення. Операції сортування використовуються для ORDER BY, DISTINCT. Хеш-таблиці використовуються в приєднаннях хешу, хеш-базованому накопичуванні і обробці підзапитів IN.
maintenance_work_mem (integer)
Визначає максимальний обєм памяті для використання операцій типу VACUUM, CREATE INDEX, і ALTER TABLE ADD FOREIGN KEY. По замовчуванню 16 Мю. Оскільки одна з цих операцій може працювати одночасно в сесію бази даних, а інсталяція не має багато одночасних їх запусків, безпечно ставити це число набагато більшим , ніж work_mem. Це покращить роботу в вакуумуванні і відновленні дампів.
Зауважте, що коли запускається автовакуум, може бути задіяно autovacuum_max_workers цієї памяті, тож не встановлюйте це значення надто високо.
max_stack_depth (integer)
Задає максимальне безпечне значення глибини стеку виконання. Ідеальним значенням є актуальне обмеження стеку ядра, встановлене як ulimit –s, менше в межах мегабайта. Ця границя потрібна тому, що глибина стеку не перевіряється в кожній операції, а тільки в потенційно рекурсивних операціях. Значення по замовчуванню – 2 Мб, що мало і не мало би спричинити пмилоки. Але вото може бути надто малим для виконання складних функцій. Тільки суперкористувачі можуть міняти це значення.
Встановлення max_stack_depth більшим, ніж ліміт ядра може спричинити помилку роботи процесу. На платформах, де PostgreSQL сам визначає цей ліміт, сервер не дозволить встановити неприпустиме значення. Але не всі платформи надають цю інформацію, тож краще бути уважним.
18.4.2. Використання ресурсів ядра.
max_files_per_process (integer)
Задає максимальну кількість відкритих файлів на кожен підпроцес сервера. По замовчуванню це тисяча файлів. Якщо ядро має обмеження, вам не потрібно хвилюватись про цей параметр. Але на деяких платформах якдро дозволить відкривати набагато більше файлів, ніж пітдтримує система, якщо багато процесів відкриють багато файлів. Ви побачите це “Too many open files”. В такому випадку зменшіть це значення. Цей параметр задається при запуску сервера.
shared_preload_libraries (string)
Ця змінна щадає одну або більше бібліотек загального доступу для попереднього завантаження. Для прикладу ’$libdir/mylib’ призведе до завантаження mylib.so із стандартного каталогу бібліотек. Якщо завантажується більше однієї бібліотеки, розділіть їх комами. Цей параметр встановлюється при запуску сервера.
Бібліотеи процедурної мови PostgreSQL можуть завантажуватись з використанням ’$libdir/plXXX’ де XXX це pgsql, perl, tcl, або python.
Завантаженням бібліотеки загального доступу, уникається час старту бібліотеки. Хоча час для створення нового серверного процесу зросте, навіть якщо процес не буде використовувати бібліотеку. Тож цей параметр рекомендується для бібліотек, що будуть використовувати в більшості сесій.
Зауваження: на хостах Віндовс, попереднє завантаження бібліотек не зменшить час запуску нового процесу, кожен процес буде наново перезавантажувати ці бібліотеки. Хоча, shared_preload_libraries потрібні на Віндовс, оскільки деякі бібліотеки мають виконувати деякі операції до запуску постмастера (для прикладку, бібліотека має зарезервувати ключі чи пам'ять загального доступу і не зробить цього після запуску постмастера).
Якщо бібліотека не знаходиться, сервер не запустаться.
Кожна бібліотека, що підтримується PostgreSQL, має магічний блок, що гарантує сумісність. Тому бібліотеки, що не належать до PostgreSQL, не завантажаться цим шляхом.
18.4.3. Затримка, базована на вазі.
Впродовж виконання команд VACUUM і ANALYZE система використовує внутрішній лічи льник, що підраховує вагу проведених операцій вводу-виводу. Коли ця вага досягає ліміту, заданого змінною vacuum_cost_limit, процес, що виконує цю операцію, переходить в режим сну на короткий період часу, що задається в vacuum_cost_delay. Він обнуляє лічильник і продовжує виконання.
Це дозволяє адміністраторам уникнути проблем вводу-виводу при багатосторонньому доступі до даних. Є багато ситуацій, де потрібно, щоб команди типу VACUUM і ANALYZE, але зазвичай важливіше, щоб ці команди не перешкоджали можливоті системи виконувати інші операції.
Ця опція відключена для заданих вручну команд VACUUM . Щоб включти її, встановіть змінній vacuum_cost_delay ненульове значення.
vacuum_cost_delay (integer)
Довжина часу, в мілісекундах, на який процес засипає при досягненні ліміту. По замовчуванню – нуль, що відключає дану опцію. Значення більше нуля її включає. Зауважте, що на багатьох системах розділення періодів сну – 10 мілісекунд. Встановлення значення, що не ділиться на 10, буде збільшувати це значення до найближчого множника 10.
Коли використовуєте затримку, що залежить від ваги, зазвичай значеннями є малими, 10 або 20 мілісекунд. Установка споживання ресурсів встановлюється іншими параметрами.
vacuum_cost_page_hit (integer)
задає вагу вакууму в буфері, знайденому в кеші буферу. Вона показує вагу закриття простору буферу, пошуку по хеш-таблиці і скануванні вмісту сторінки. По замовчуванню 1.
vacuum_cost_page_miss (integer)
Значення ціни для вакууму в буфері, зчитаному з диска. Преставляє спробу закрити простір буферу, передивитись хеш-таблицю, прочитати потрібний блок і сканувати його контент. По замовчуванню 20.
vacuum_cost_page_dirty (integer)
Ціна модифікацій блоку, що був очищений. Показує додаткові операцій вводув виводу для повернення блоку на диск. По замовчуванню 20.
vacuum_cost_limit (integer)
Сумарне значення, що відправить процес в режим сну. По замовчуванню 200.
Зауваження: є декілька операцій, що мають критичні замки і мають виконуватись якнайшвидше. Затримка, базована на вазі, на них не впливає. Тому можливо, що значення буде перевищено. Щоб уникнути надтодовгої затримки в таких випадках, подібна затримки рахується як: vacuum_cost_delay*accumulated_balance/ vacuum_cost_limit з максимумом vacuum_cost_delay * 4.
18.4.4. Фоновий записник.
Існує окремий сервер процесу, що називається фоновим записником, чия функція є запис брудних (нових, або модифікованих) буферів загального доступу. Він записує буфери, тож серверні процеси, які працюють із запитами, не мають очікувати на закінчення запису. Хоча це впливає на роботу завантаження вводу-виводу, оскільки постійно перезаписувана сторніка має записуватись тільки раз за певний інтервал часу, фоновий записник записує її декілька разів. Параметри, обговорювані в цьому підрозділі можуть використовуватись для налаштування поведінки для локальних потреб.
bgwriter_delay (integer)
Задає затримку між активністю фонового записника. В кожному раунді записник записує деяку кількість брудних буферів. Потім він засинає на bgwriter_delay мс, і продовжує. По замовчуванню значення 200 мс. Зауважте, що на багатьох системах розділення періодів сну – 10 мілісекунд. Встановлення значення, що не ділиться на 10, буде збільшувати це значення до найближчого множника 10. Цей параметр задається в файлі postgresql.conf або в командному рядку сервера.
bgwriter_lru_multiplier (floating point)
Число брудних буферів, охоплених одним раундом базується на числі нових буферів, що потребуються процесам впродовж останніх раундів. Це значення домножується на bgwriter_lru_multiplier, щоб отримати знчення буферів, що будуть потрібні в наступному раунді. Брудні буфери записуються, доки є чисті буфери. (Але не дозволено запис більш ніж bgwriter_lru_maxpages за раунд). Значення 1.0 представляє правило запису стількох буферів, скільки потребуються. Більші значення дають деякий запас, тоді як менші значення залишають записи серверним процесам. По замовчуванню 2.0. Цей параметр задається в файлі postgresql.conf або в командному рядку сервера.
Менші значення bgwriter_lru_maxpages і bgwriter_lru_multiplier видаляють додаткове навантаження записника, але тоді серверні процеси будуть змушені робити записи самостійно, відкладаючи інтерактивні запити.
18.4.5. Асинхронна поведінка.
effective_io_concurrency (integer)
Задає число конкурентних операцій I/O, які очікує на виконання PostgreSQL. Підвищення цього значення збільшить число операцій вводу-виводу, які може паралельно ініціювати кожна сесія. Дозволене значення – від 1 до 1000, або 0 для відключення асинхронних запитів.
Хорошою стартовою точкою для цього значення буде число окремих дисків, що представляють смугу RAID 0 або дзеркало RAID 1, що використовується для бази даних. (для RAID 5 диск парності не рахується). Хоча, якщо база даних часто занята багатьма запитами в конкуруючих сесіях, нижчі значення будуть ефективними для хорошої зайнятості дискового масиву. Значення більше ніж потрібно, щоб завантажити диски, буде спричиняти навантаження процесора.
Для більш екзотичних систем, як масив RAID, обмежений шириною шини, правильним значенням буде число доступних шляхів вводу-виводу. Потрібні деякі експерименти для знаходження оптимального значення.
Асинхронний ввід-вивід залежить від ефективної функції posix_fadvise, які упускають деякі ОС. Якщо функція на представлена, тоді встановлення цього параметра у значення, відмінне від 0, спричинить помилку. На деяких операційних системих (наприклад, Соляріс), функція присутня, але вона нічого не робить.
18.5. Запис логів
Дивіться розділ 29.4 для подробиць налаштування WAL.
18.5.1. Установки
wal_level (enum)
wal_level визначає, скільки інформації записується в WAL. По замовчуванню значення minimal, що записує тільки інформацію, потрібнуд для відновлення від помилки чи несанкціонованого вилючення. Archive додає записи для архівування WAL, а hot_standby додає інформацію про запити читання на сервері. Цей параметр задається при запуску сервера.
На рівні minimal запис операцій, типу CREATE INDEX, CLUSTER і COPY, на таблиці, що була створена в цй же транзакції, буде безпечно відмінено, що зробить ці операції швидшими. Але мінімальний WAL не містить інформацій для реконструкції даних з бекапу і логів WAL, тож archive або hot_standby має використовуватись для архівування WAL і поточного відновлення.
На рівні hot_standby така ж інформація, як в archive, плюс інформація, потрібна для реконструкції статусу запущених транзакцій з WAL. Щоб включити запити читання на сервері wal_level має бути встановлений в hot_standby і hot_standby має бути включеним. Є різниця між виконанням рівнів ghot_standby і archive , тож відписуйте, якщо зустрілися з конфліктами продуктів.
fsync (boolean)
Якщо цей параметр включено, сервер PostgreSQL спробує впевнитись, що всі оновлення фізично встановлені на диск, використанням системного виклику fsync() або еквівалентних методів (дивіться метод wal_sync_method). Це забезпечує можливість відновлення кластеру бази даних до нормального стану після збою системи.
Оскільки відключення fsync, це може спричинити невідновлюваний збій даних у випадку збою системи. Рекомендовано відключати fsync тільки, якщо ви можете відновити дані з зовнішнього джерела.
Приклади безпечного виключення fsync включають завантаження кластеру з файлу бекапу, використовуючи кластер для статистики на базі годин, що потім перестворюється, або для звітів клону бази даних для читання, який відновлюється швидко. Тільки надійність апаратного забезпечення є недостатньою умовою для відключення fsync.
В багатьох ситуаціях, відключення synchronous_commit для некритичних транзакцій може забезпечити більше користі у виконанні, ніж відключенння fsync, і без ризику пошкодження даних.
Fsync встановлюється тільки в postgresql.conf, або з командного рядка. Якщо ви відключите цей параметр, пересвідчіться у відключенні full_page_writes.
synchronous_commit (boolean)
Задає, чи виконання транзакції буде чекати на закінчення записів WAL на диск перед тим, як команда поверне сигнал успішного завершення. По замовчуванню і для безпеки, опція включена. Коли виключена, може бути затримка між звітом клієнту і тим, коли транзакція буде дійсно безпечна. (максимальна затримка – три періоди wal_writer_delay). На відміну від fsync, вимкнення цього параметру не створює ніякого ризику для даних. Збій просто втратить дані про здійснення деяких транзакцій, а дані будуть в тому ж стані, що до цих змін. Тож, виключення функції може бут виключеним як альтернатива, коли виконання важливіше безпеки транзакцій. Більше в розділі 29.3.
Цей параметр можна міняти в будь-який ча. Поведінка для кожної транзакції визначається цією опцією. Можливо та корисно, щоб деякі транзакції виконувались синхронно, а деякі – ні. Для прикладу, щоб зробити одну багатовиразну транзакцію асинхронно, використайте SET LOCAL synchronous_commit TO OFF всередині транзакції.
wal_sync_method (enum)
Метод, що використовується для оновлення WAL на диску. Якщо fsync виключена, ця опція недоступна, оскільки файлів не буде взагалі. Можливі значення:
open_datasync (запис файлів WAL з допомогою опції open() O_DSYNC)
fdatasync (виклик fdatasync())
fsync_writethrough (виклик fsync() з примусовим записом в кеш диска)
fsync (викликає fsync())
open_sync (записує файли WAL з опцією open() O_SYNC)
Не всі з цих виборів доступні на всіх платформах. По замовчуванню це перший метод із тих, що підтримуються платформою в цьому списку. Використовуйте опції open_* і O_DIRECT, якщо можна. Утиліта src/tools/fsync в PostgreSQL може виконувати тестування роботи для різних методів fsync. Цей параметр задається з файлу postgresql.conf або в командному рядку сервера.
full_page_writes (boolean)
Коли цей параметр включений, сервер PostgreSQL записує контент кожної сторінки диска в WAL впродовж першої модифікації цієї сторінки після точки збереження. Це потрібно тому, що запис на сторінці при збої системи може містити і старі і нові дані. Дані, що зберігаються в WAL, не достатні для відновлення сторінки, але збільшенням обєму даних у WAL, це можна зробити. Зберігання образу всієї сторінки гарантує, що її успішно відновлять. (оскільки запуск WAL завжди починається з точки збаражання, ефективно робити це впродовж першої зміни сторінки після збереження. Щоб зменшити навантаження на систему, можна збільшити інтервали між збереженням).
Вимкнення цього параметру прискорює роботу, але може призвести до неможливості відновлення даних.
Вимкнення параметру не впливає на використання WAL для PITR (розділ 24.3).
Цей параметр задається в postgresql.conf, або з командного рядка сервера.
wal_buffers (integer)
Обєм памяті, що використовується для даних WAL. По замовчуванню 64 Кб. Занчення має бути достатнім для зберігання даних однієї транзакції, доки вона не виконається. Задається при запуску сервера.
Збільшення цього параметра призводить до збільшення потреб у памяті загального доступу. Більше про установку цих параметрів у розділі 17.4.1.
wal_writer_delay (integer)
Визначає затримку між раундами активності записника WAL. В кожному раунді значення записів передається на диск. Потім програма очікує wal_writer_delay мілісекунд і повторює операцію. По замовчуванню – 200 мс. Зауважте, що на багатьох системах розділення періодів сну – 10 мілісекунд. Встановлення значення, що не ділиться на 10, буде збільшувати це значення до найближчого множника 10. Цей параметр задається в файлі postgresql.conf або в командному рядку сервера.
commit_delay (integer)
Затримка в часі між записом в буфер WAL і його видаленням з диска. Ненульова затримка дозволяє декілька транзакцій з одним викликом fsync(), якщо завантаження системи достатньо високе, що додаткові транзакції готові до виконання у визначений інтервал. Але затримка тільки тартиться впусту, якщо немає достатнього навантаження. Тому затримка працює, якщо як мінімум commit_siblings транзакцій активні. По замовчуванню – 0.
commit_siblings (integer)
Мінімальне значення конкуруючих транзакцій для вимог до виконання затримки commit_delay. Велике значення робить більш ймовірним те, що хоча б одна транзакція буде затримана на даний інтервал. По замовчуванню це 5 транзакцій.
18.5.2. точки відновлення.
checkpoint_segments (integer)
Максимальне число сегментів файлу логів між автоматичними точками відновлення (зазвичай кожен сегмент – 16 Мб). По замовчуванню – 3 сегменти. Збільшення цього параметру може збільшити час на відновлення після збою. Встановлюється в файлі postgresql.conf або командному рядку сервера.
checkpoint_timeout (integer)
Максимальний час між автоматичними точками збереження, в секундах. По замовчуванню – 5 хвилин. . Збільшення цього параметру може збільшити час на відновлення після збою. Встановлюється в файлі postgresql.conf або командному рядку сервера.
checkpoint_completion_target (floating point)
Задає ціль завершення збереження, як відсоток часу між збереженнями. По замовчуванню 0.5. Встановлюється в файлі postgresql.conf або командному рядку сервера.
checkpoint_warning (integer)
Записує повідомлення в лог, якщо збереження заповнило всі файли сегментів перед закінченням часу (що вимагає збільшення checkpoint_segments). По замовчуванню 30 секунд. 0 відключає попередження. . Встановлюється в файлі postgresql.conf або командному рядку сервера.
18.5.3. Архівування.
archive_mode (boolean)
Коли archive_mode (boolean) включений заповнені сегменти WAL віправляються в архів, встановленням archive_command. archive_mode і archive_command – це окремі змінні, тож archive_command має мінятись, не виходячи з режиму архіву. Цей параметр задається при запуску сервера. wal_level має мати значення archive або hot_standby для роботи archive_mode.
archive_command (string)
Команда оболонки для виконання архівування файлового сегменту WAL. %p в рядку заміняється на шлях файлу архіву, а %f замінюється імям файлу. (Імя відносне до каталога сервера, тобто каталога кластера бази даних). Використовуйте %% для введення символу % в команду. Важливо щоб команда повертала 0 при успішному завершенні. Більше інформації в Розділі 24.3.1.
Цей параметр встановлюється в файлі postgresql.conf або командному рядку сервера. Якщо archive_command – пустий рядок, коли archive_mod включений, архівування WAL буде тимчасово відключене, але сервер продовжить акумулювати файли в очікуванні що команда буде забезпечена. Встановлення archive_command в команду, що не повертає нічого крім true, наприклад /bin/true, відключає архівування, але також розбиває ланцюг відновлення файлів через WAL, тож має використовуватись в особливих випадках.
archive_timeout (integer)
archive_command викликається для повних сегментів WAL. Тобто, якщо ваш сервер генерує малий трафік, може бути велика затримка між транзакцією і безпечним записом в архів. Для обмеження давності неархівованих даних, ви можете встановити archive_timeout для примушення сервера періодично оновляти файл WAL. Коли цей параметр більше нуся, сервер переключиться на новий сегментний файл, незалежно від часу, що пройшов від останнього прееключення сегментного файлу і чи була якась активність бази даних, включаючи точни збереження. (збільшення значення призведе до зменшення кількості точок збереження). Зауважте, що архівовані файли, що закриті примусовим переключенням будуть такі ж завеликі, як і повні файли. Тому нерозумно використовувати дуже короткий archive_timeout – він порушить архівне зберігання. Хорошими буде параметр archive_timeout близько хвилини.
Цей параметр встановлюється в файлі postgresql.conf або командному рядку сервера.
18.5.4. Поточне відновлення.
Ці налаштування контролюють поведінку вбудованих можливостей поточного відновлення.
max_wal_senders (integer)
Задає масимальне число конкурентних зєднань із серверів (тобто число відправників WAL). По замовчуванню 0. Цей параметр задається при запуску. wal_level має бути встановленим в archive або hot_standby, щоб дозволити такі зєднання.
wal_sender_delay (integer)
Задає затримку між раундами активності відправника WAL. Кожен раунд відправник дає накопичений WAL від часу останньої відправки. Тоді він засинає на wal_sender_delay мілісекунд і посторює виконання. По замовчуванню 200 мс. Зауважте, що на багатьох системах розділення періодів сну – 10 мілісекунд. Встановлення значення, що не ділиться на 10, буде збільшувати це значення до найближчого множника 10. Цей параметр задається в файлі postgresql.conf або в командному рядку сервера.
wal_keep_segments (integer)
Задає кількість сегментів старих логів в каталозі pg_xlog, якщо сервер потребує їх для поточного відновлення. Кожен сегмент зазвичай 16 Мб. Якщо сервер приєднаний до більш ніж wal_keep_segments, перший може стерти сегмент WAL, що буде потрібен серверу, і зєднання буде перервано.
Це встановлює тільки мінімальне число сегментів для потреб цих серверів. Система може потрбувати більше сегментів. Якщо wal_keep_segments рівне 0 (по замовчуванню), система не тримає додаткових сегментів і число сегментів WAL для серверів визначається розміщенням попередньої точки збереження і статусу архівування. Цей параметр задається в файлі postgresql.conf або в командному рядку сервера.
18.5.5. Резервні сервери.
hot_standby (boolean)
Визначає чи ви хочете підключати і запускати запити протягом відновлення, як описано в розділі 25.5. По замовчуванню вимкнуто. Цей параметр задається при запуску сервера. Він має ефект тільки протягом відновлення архіву або в режимі очікування.
max_standby_delay (integer)
Коли цей режим активний, цей параметр задає правила для роботи WAL, що конфліктують з активними запитами. Якщо виникає конфлікт, сервер відкладає операцію до відміни конфліктуючих запитів, ак описано в розділі 25.5.2. По замовчуванню 30 секунд. Одиниці вимірювання – мілісекнди. Значення -1 задає постійне очікування виконання запиту. Цей параметр задаєтсья в postgresql.conf або командному рядку сервера.
Велике значення робить відміну запиту малоймовірною. Збільшення параметру або установка його в -1 відкладає появу змін на сервері мастера на резервному сервері.
Хоча хочеться вірити, що max_standby_delay – це максимальний час роботи запитів, це не правда. Коли закінчується довгий запит, є час, що потрібен для зміни логів WAL. Якщо новий запит спрацьовує до закінчення роботи WAL, значення для 2-го запиту буде набагато меншим ніж max_standby_delay перед тим, як буде можлива відміна.
18.6. Планування запитів.
18.6.1. Конфігурація методів планування.
Ці параметри конфігурації забезпачують метод планування запиті, вибраних оптимізатором запитів. Якщо вибраний план по замовчуванню не є оптимальний, тимчасовим рішенням буде зміна цього плану на інший. Кращим способом покращення якості планів є задання констант аналізатора, запуск вручну ANALYZE, збільшення значення параметра default_statistics_targe і збільшення кількості статистики, зібраної за допомогою ALTER TABLE SET STATISTICS.
enable_bitmapscan (boolean)
Включає або виключає використання плану bitmap-scan. По замовчуванню включено.
enable_hashagg (boolean)
Включає або виключає використання плану hashed aggregation. По замовчуванню включено.
enable_hashjoin (boolean)
Включає або виключає використання плану hash-join. По замовчуванню включено.
enable_indexscan (boolean)
Включає або виключає використання плану index-scan. По замовчуванню включено.
enable_material (boolean)
Включає або виключає використання матеріалізації. Неможливо вплинути на неї явно, але виключення цієї змінної запобігне вставлянню матеріальних одиниць, крім випадків, коли це необхідно для коректності. По замовчуванню включено.
enable_mergejoin (boolean)
Включає або виключає використання плану merge-join. По замовчуванню включено.
enable_nestloop (boolean)
Включає або виключає використання плану nested-loop join. Неможливо відмінити його явно, але відключення цієї змінної запобігне використанню його, якщо інші методи доступні. По замовчуванню включено.
enable_seqscan (boolean)
Включає або виключає використання плану sequential. Неможливо відмінити його явно, але відключення цієї змінної запобігне використанню його, якщо інші методи доступні. По замовчуванню включено.
enable_sort (boolean)
Включає або виключає використання явного сортування. Неможливо відмінити його явно, але відключення цієї змінної запобігне використанню його, якщо інші методи доступні. По замовчуванню включено.
enable_tidscan (boolean)
Включає або виключає планування з використанням планів TIDscan. По замовчуванню включено.
18.6.2. Константи ціни планувальника.
Змінні ціни описані в цьому розділі вимірюються відносними значеннями. По замовчуванню, ці константи базовані на ціні послідовної вибірки сторінки. Це seq_page_cost є 1.0 і всі решта отримують ціну відносно неї. Але ви можете використовувати іншу шкалу, як наприклад виконання операції в мілісекундах.
Зауваження: на жаль, немає визначеного методу для задання ідеальних значень для змінних цін. Вони взяті як середнє з вибірки запитів, що отримує окрема інсталяція. Зміна їх задля експериментів є досить ризикованою.
seq_page_cost (floating point)
Задає кошт вибірки сторінки з диска, що є частиною вибірок. По замовчуванню 1.0 Це значення можна міняти для окремого простору таблиці заданням параметра з цим же імям (через ALTERTABLESPACE).
random_page_cost (floating point)
Задає кошт операції, що не є вибіркою сторінки з диска. По замовчуванню 4.0. Це значення можна міняти для окремого простору таблиці заданням параметра з цим же імям (через ALTERTABLESPACE).
Зменшення цього значення до seq_page_cost заставить систему надавати перевагу індексним скануванням. Збільшення його призведе до збільшення ціни індексних сканувань. Ви можете збільшити або зменшити ціни зміни значення операцій диска відносно операцій процесора., які описані наступними параметрами.
Підказка: хоче система дозволить задати вам random_page_cost менше за seq_page_cost, це не дасть нічого. Встановлення їх рівними має сенс, якщо база даних кешується в ОЗП, в цьому випадку нема штрафів для вибірки сторінок. Також база даних з важким кешем має мати понижені значення відносно параметрів процесора, оскільки вибірка зі сторінки в ОЗП менша ніж може бути.
cpu_tuple_cost (floating point)
Задає кошт обробки рядка. По замовчуванню 0.01.
cpu_index_tuple_cost (floating point)
Задає кошт сканування індексу. По замовчуванню 0.005.
cpu_operator_cost (floating point)
Задає кошт сканування оператора або функції запиту. По замовчуванню 0.0025.
effective_cache_size (integer)
Задає висновки планувальника про ефективний розмір дискового кешу, який доступний для окремого запиту. Він пропорційний кошту використання індекса. Більше значення робить більш ймовірним використання індексного сканування, менше робить більш ймовірним вибіркове сканування. Коли встановлюєте це значення, знайте, що для файлів даних буде викристовуватись пам'ять загального доступу і кеш диска ядра. Також подивіться до очікуваного числа конкурентних запитів на різних таблицях, оскільки вони будуть ділити доступнй простів. Цей параметр не має ефекту на розмір памяті загального доступу, заданого в PostgreSQL, і він не резервує дисковий кеш. Він використовується тільки для оцінки. По замовчуванню 128 Мб.
18.6.3. Генетичний оптимізатор запитів.
Генетичний оптимізатор запитів – це алгоритм, що викорує планування запитів з допомогою евристичного пошуку. Це зменшує час планування для складних запитів. За рахунок виведення планів, що деоли більше за ті, що формуються алгоритмом по замовчуванню. Також GEQO рандомізований і його поведінка не є детермінованою.
geqo (boolean)
Включає або виключає оптимізатор. Включений по замовчуванню, краще не відключати. Його geqo_threshold забезпечеє більше контролю.
geqo_threshold (integer)
Використовує оптимізацію запитів з багатьма включеними FROM. Зауважте, що конструкція FULL OUTER JOIN виводиться як один юніт FROM. По замовчуванню 12. Для простих запитів краще викристовувати детермінований планувальним, але для великих запитів він працює надто довго.
geqo_effort (integer)
Контролює пересилання між часом планування і якістю планування. Ця змінна – ціле число від 1 до 10. По замовчуванню 5. Більші значення збільшують час на планування, але збільшують шанси на те, що це планування буде найефективнішим.
geqo_effort не робить нічого напряму. Вона задається для обчислення значень по замовчуванню для змінних, що впливають на поведінку GEQO. Якщо хочете, можете змінити ці параметри вручну.
geqo_pool_size (integer)
Контролює простів, що є кількістю індивідів генетичної популяції. Має буди як мінімум 2, типовим значенням є від 100 до 1000. Якщо параметр заданий в 0, тоді значення вибирається на базі geqo_effort і числа таблиць в запиті.
geqo_generations (integer)
Контролює кількість поколінь, що використовуються GEQO, що є числом ітерацій алгоритму. Має бути як мінімум 1, прийнятне значення базується на geqo_pool_size.
geqo_selection_bias (floating point)
Контролює вибір схилення, що використвується в GEQO. Це вибірковий тиск всередині популяції. Значення від 1.50 до 2.00, останнє по замовчуванню.
geqo_seed (floating point)
Контролює значення генератора випадкових чисел GEQO. По замовчуванню значення від 0 до 1. Зміна значення міняє набір шляхів перевірки, може впливати на пошук шляху як краще, так і гірше.
18.6.4. Інші опції планування.
default_statistics_target (integer)
Задає ціль статистики для колонок таблиці без специфікованої цілі через ALTER TABLE SET STATISTICS. Більші значення збільшують час на ANALYZE, але покращують висновки. По замовчуванню 100. Для інформації, дивіться 14.2.
constraint_exclusion (enum)
Контролює використання планувальником запитів обмежень таблиць для оптимізації. Дозволені значення – on (для всіх таблиць), off (не перевіряти обмеження) і partition (тільки для похідних таблиць і підзапитів UNION ALL). Partition – значення по замовчуванню. Використовується з успадкуванням і таблицями для покращення виконання.
Коли цей параметр дозволяє для часткової таблиці, планувальник порівнює умови запиту з обмеженнями CHECK і уникає сканування таблиць, у яких нема подібних значень. Для прикладу:
CREATE TABLE parent(key integer, ...);
CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);
CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
...
SELECT * FROM parent WHERE key = 2400;
З обмеженням цей SELECT не просканує child1000 взагалі, покращуючи роботу.
Зараз перевірка обмежень включеня тільки для випадків, що використовують виконання розбиття таблиці. Включення їх для усіх таблиць навантажує компютер, що добре для прости х запитів. Якщо ви не маєте розбитих таблиць, можете відключити її. Дивіться розді 5.9.4 для пдальшої інформації.
cursor_tuple_fraction (floating point)
Задає планувальнику час роботи з рядком курсору. По замовчуванню 0.1. Менші значення призводять для виокристання швидкого старту планів, і перевіряють швидше перші рядки і довго – наступні. Більші значення додають більше загального часу. На максимальному значенні 1.0. Курсори плануються як звичайні запити.
from_collapse_limit (integer)
Планувальник обєднає підзапити в запити, якщо список FROM буде мати більше, ніж таку кількість частин. Менші значення зменшують час планування, але збільшують час виконання запиту. По замовчуванню 8. Більше в розділі 14.3.
Встановлення цього значення в geqo_threshold або більше, змінить використання GEQO, видавши непередбачувані плани. Більше в 18.6.3.
join_collapse_limit (integer)
Планувальник перепише явні конструкції JOIN (крім FULL JOIN) в списках FROM. Менші значення зменшують час планування, але зменшують ефектифність запитів.
По замовчуванню, ця змінна встновлюється як from_collapse_limit, яка використовується в більшості випадків. Оскільки планувальник запитів не завжди вибирає потрібний порядок, деякі користувачі можуть вибратитимчасову установку цієї змінної в 1, і задають порядок приєднання явно. Більше в розділі 14.3.
Встановлення цього значення в geqo_threshold або більше, змінить використання GEQO, видавши непередбачувані плани. Більше в 18.6.3.
18.7. Звіти та зберігання помилок.
18.7.1. Куди зберігати
log_destination (string)
PostgreSQL підтримує декілька методів для запису серверних повідомлень, включаючи stderr, csvlog і syslog. На віндовс також підтримується eventlog. Встановлення цього параметра до списку бажаних розміщень логів розділених комами. По замовчуванню є тільки запису stderr цей параметр може бути заданий в файлі postgresql.conf або в командному рядку сервера.
Якщо Csvlog включений в log_destination, виходом будуть значення, розділені комами, що зручно для завантаження в програми. Дивіться розділ 18.7.4. для деталей.
Зауваження: в більшості систем Unix вам потрібно змінити конфігурацію ваших системних логів, щоб зробити можливим викристання log_destination. PostgreSQL може записувати до LOCAL0 через LOCAL7, але по замовчуванню конфагурація на більшості платформах буде відкидати такі повідомлення. Вам потрібно додати щось типу local0.* /var/log/postgresql до файлу коонфігурації демона логів.
logging_collector (boolean)
Цей параметр захоплює звичайні та CSV повідомлення, відіслані stderr і перенаправляє їх в файли логів. Я використовується частіше, ніж запис в syslog, оскільки деякі типи повідолень не звявляються в syslog (типовий приклад – помилка динамічного звязування). Цей прааметр задається при запуску сервера.
Зауваження: збирач логів зроблений щоб не пропускати повідомлення. У випадку сильного завантаження, серверні процеси можуть бути замкнені під час відсилання логів колектору. Тоді як syslog відкидає повідомлення, які не може прийняти, що впливає на надійність, але не гальмує систему.
log_directory (string)
Коли logging_collector включений, цей параметр визначає каталог, в якому створюються файли логів. Він може задаватись як абсолютний шлях або відносно каталога даних кластера. Цей параметр задається в postgresql.con або в командному рядку.
log_filename (string)
Коли logging_collector включений, цей параметр визначає імена файлів, в які створюють файли логів. Значення є шаблоном strftime, тож % мое використовуватись для залежних від часу імен файлів. (зауважте, що якщо є залежні від чаосого поясу виходи %, обчислення робиться за часовим поясом). Зауважте, що якщо strftime не використовується напряму, тому нестандартні розширення працювати не будуть.
Якщо ви задасте імя файлу без виходів, ви маєте використовувати утиліту заміни для запобігання переповнення дичеу. В релізах до 8.4, якщо не було виходів %, програма додавала до імені дату створення, але зараз цього не має.
Якщо включено формат CSV в log_destination, то .csv буде прикріплено до файлу логів щоб створювати файл логів формату виводу CSV. (Якщо log_filename закінчується на .log, додається суфікс). У випадку прикладу вище, файл буде мати назву server_log.1093827753.csv.
Цей параметр задається в файлі postgresql.conf або командному рядку сервера.
log_rotation_age (integer)
Коли включений logging_collector, цей параметр визначає максимальний час життя окремого файлу логів. Коли ці хвилини пройшли, свторюється новий файл логів. Встановлення в нуль відключає створення нових файлів з часом. Цей параметр задається в файлі postgresql.conf або командному рядку сервера.
log_rotation_size (integer)
Коли включений logging_collector, цей параметр визначає максимальний розмір окремого файлу логів. Коли ця кількість кілобайт вийша, створюється новий файл. Значення 0 відключає цю опцію. Цей параметр задається в файлі postgresql.conf або командному рядку сервера.
log_truncate_on_rotation (boolean)
Коли включений logging_collector, цей параметр заставить PostgreSQL перезаписати існуючий файл логів з таким же іменем. Але це буде тільки тоді, коли новий файл відкритий згідно ротації, базованої на часі, а не запуску сервера. Коли виключено, існуючі файли будуть приєднані в будь-якому випадку. Для прикладу, використання цієї опції в комбінації з log_filename типу postgresql-%H.log дасть генерацію 24-годинних файлів журналу і циклічно буде їх перезаписувати. Цей параметр задається в файлі postgresql.conf або командному рядку сервера.
Приклад: щоб мати 7 днів логів, один лог на день з назвою server_log.Mon, server_log.Tue, і перезаписує логи попереднього тижня. Встановіть server_log.%a, log_truncate_on_rotation на ввікнений і log_rotation_age на 1440.
syslog_facility (enum)
Коли включений запис у syslog цей параметр задає службу syslog, що використовуєється. Ви можете вибрати із LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7, по замовчуванню - LOCAL0. Дивіться також документацію вашого демона запису логів. Цей параметр задається в файлі postgresql.conf або командному рядку сервера.
syslog_ident (string)
Коли запис в syslog включено, цей параметр визначає імя програми, що використовується для ідентифікації повідомлень PostgreSQL в логах. По замовчуванню postgres. Цей параметр задається в файлі postgresql.conf або командному рядку сервера.
silent_mode (boolean)
Запускає сервер тихо. Якщо цей параметр встановлено, сервер запускається в фоні і відєднується від терміналу. Задається при запуску сервера.
18.7.2. Коли записувати.
client_min_messages (enum)
Контролює які рівні повідомлень відправляються клієнту. Значеннями є DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR, FATAL, і PANIC. Кожен рівень включає всі рівні, що йдуть за ним. Чим дальший рівень – тим менше повідомлень. По замовчуванню NOTICE. Зауважте, що LOG має інший рівень, ніж в log_min_messages.
log_min_messages (enum)
Контролює, який рівень записується в серверний лог. Значеннями є DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, і PANIC. Кожен рівень включає всі рівні, що йдуть за ним. Чим дальший рівень – тим менше повідомлень. По замовчуванню WARNING. Зауважте, що LOG має інший рівень, ніж в client_min_messages (enum)
log_min_error_statement (enum)
Контролює, які вирази SQL, що викликають помилку записуються в серверний лог. Поточний вираз включає будь-який вираз цього рівня і вище. Значеннями є DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, і PANIC. По замовчуванню ERROR, що означають вирази, що спричиняють помилки, фатальні помилки чи паніки. Щоб відключити запис помилок виразів, переключіться в PANIC. Тільки суперкористувачі можуть міняти цю опцію.
log_min_duration_statement (integer)
Спричиняє запис тривалості виразу, якщо він працював як мінімум зазначену кількість мілісекунд. Встановлення цього в нуль виводить всі тривалості.-1 відключає їх. Для прикладу, якщо ви поставите 250ms, тоді всі вирази SQL що тривали довше 250ms будуть записані. Це допомагає у виловлюванні неоптимізованих запитів у додатках. Тільки суперкористувачі можуть міняти це значення.
Для клієнтів, що використовують розширений протокол запитів, тривалість кроків Parse, Bind, і Execute записується незалежно.
При використанні цієї опції з log_statement, текст виразів які записанів log_statement не буде повторятись в лозі тривалості. Якщо ви не використовуєте syslog, рекомендовано записувати PID або ID сесії використанням log_line_prefix дя посилання на повідолення виразу для інших повідомлень ,що використовують ID процесу або ID сесії.
Таблиця 18-1 пояснює рівні, що використовуються в PostgreSQL. Якщо вивід віправляється в syslog або Windows’ eventlog, ці рівні транслюються ,як показано в таблиці.
18.7.3. Що записувати
application_name (string)
це може бути будь-який рядок, менший ніж NAMEDATALEN символів (зазвичай 64). Він встановлюється додатком при підключенні до сервера. Імя буде виводитись в pg_stat_activity і включатись в логи CSV. Воно може бути включеним в логи через параметр log_line_prefix. Мають використовуватись тільки символи ASCII, інші символи заміняться знаком запитання.
debug_print_parse (boolean)
debug_print_rewritten (boolean)
debug_print_plan (boolean)
Ці параметри включають різний вивід відладки. При встановленні пони виводять дерево проходження, преезаписувач запиту, або план виконання кожного запиту. Ці повідовлення включаються в рівень LOG, тож по замовчуванню вони появляться в лозі сервера, але на відправлятимусть клієнту. Ви можете це змінити задавши client_min_message і log_min_messages. Ці параметри вимкнені по замовчуванню.
debug_pretty_print (boolean)
Коли встановлюється debug_pretty_print включає поідомлення debug_print_parse, debug_print_rewritten і debug_print_plan. Результат більш читабельний, але довший. Включене по замовчуванню.
log_checkpoints (boolean)
Записує точки збереження в лог сервера. Включається деяка статистика, включаючи кількисть буферів і час їх запису. Параметр задається в postgresql.conf або командному рядку сервера.
log_connections (boolean)
Кожне зєднання на сервері записується як і вдала аутентифікація. Параметр задається в postgresql.conf або командному рядку сервера. По замовчуванню вимкнений.
Зауваження: деякі клієнтські програми, пробують підєднатись двічі, коли визначають, що потрібен пароль, тому дублікація повідомлень зєднань не є причиною проблеми.
log_disconnections (boolean)
вивиодить рядок в лозі сервера такий же як log_connections але в межах сесії і включає тривалість сесії. Параметр задається в postgresql.conf або командному рядку сервера. По замовчуванню вимкнений.
log_duration (boolean)
Записує кожен виконаний вираз. Вимкнено по замовчуванню, змінити можуть тільки суперкористувачі.
Для клієнтів, що використовують розширений протокол запитів, Parse, Bind і Execute записуються незалежно.
Зауваження: різниця міє встановленням цієї опції і log_min_duration_statement в нуль є те що log_min_duration_statement записує текст запиту, а ця опція ні. Якщо log_duration включена і log_min_duration_statement має додатнє значення, всі операції записуються, але запит включається тільки для виразів, що розширюють threshold. Ця поведнка використовується для збирання статистики в навантажених інсталяціях.
log_error_verbosity (enum)
Контролює обєм деталей, що записується в лог сервера для кожного повідомлення. Значеннями є TERSE, DEFAULT, і VERBOSE, кожен додає більше полів для виведених повідомлень. Тільки суперкористувачі можуть міняти цю опцію.
log_hostname (boolean)
По замовчуванню, логи зєднань показують тільки ІР-адреси хостів. Включення цього параметра показує імена хоств. Зауважте, що це може спричинити затримку виконання. Цей параметр задається в postgresql.conf або в командному рядку.
log_line_prefix (string) це рядок, що є початком будь-якого файло логів. % замінюється інформацією, як показно нижче. Невідомі виходи ігноруються .Інші символи копіюються в рядок логу. Деякі виходи розпізнаються процесами сесії і ігноруються процесом головного сервера. Цей параметр задається в postgresql.conf або в командному рядку сервера. По замовчуванню пустий рядок.
Вихід %c виводить ідентифікатор сесії із двох 4-байтних шістнадцяткових чисел, розділених крапкою. Числа – час старту процесу і ідентифікатор процесу, тож %c може використовуватись для зберігання місця. Для прикладу, щоб згенеруванти ідентифікатор сесії для pg_stat_activity, використайте запит:
SELECT to_hex(EXTRACT(EPOCH FROM backend_start)::integer) || ’.’ ||
to_hex(procpid)
FROM pg_stat_activity;
Якщо ви встановили непусте значення для log_line_prefix, ви маєте зробити його останнім символом пробіль, двя відділення в решті рядка логів. Знак пунктуації також може використовуватись.
Syslog дає власне значення часу та ID ви можете не хотіти використовувати ці виходи про використанні syslog.
log_lock_waits (boolean)
Контролює чи повідолення видається , коли сесія працює довше 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 також включаються, якщо команда, що їх використовує, має заданий тип. Для клієнтів, що використовуються протокол розширених запитів, запис відбувається при отриманні Execute і включаються значення параметрів Bind.
По замовчуванню none. Тільки суперкористувачі можуть міняти цю опцію.
Зауваження: вирази, що містять прості синтаксичні помилки не записуються значенням log_statement = all, оскільки запис відбувається тільки після перевірки типу виразу. У випадку розширеного запиту, ця опція не записує вирази, що помиляються до фази Execute. Встановіть log_min_error_statement в ERROR (або нижче) щоб записувати такі вирази.
log_temp_files (integer)
контролює запис імен і розмірів тимчасових файлів. Тимчасові файли можуть створюватись для сортування, хешів і тимчасових результатів запитів. Лог робиться коли тимчасовий файл видаляється. Значення 0 записує всю інформацію тимчасових файлів, тоді як додатні значення записують тільки файли, чий розмір є більшим або рівним заданому числу кілобай. По замовчуванню -1, що відключає ці логи. Тільки суперкористувачі можуть міняти це значення.
log_timezone (string)
Задає часовий пояс, що використовується для часу в логах. Це значення поширюється на кластер, тож всі сесії будуть віддавати однаковий час. По замовчуванню unknown, що означає, що часовий пояс задає система. Цей параметр міняється в postgresql.conf або командному рядку сервера.
18.7.4. використання виводу формату CSV
Включення csvlog в список log_destination забезпечує зручний спосіб імпортувати файли логів в таблицю бази даних. Ця опція задає рядки логів, розділені комою, з такими стовпцями: час в мілісекундах, імя користувача, імя бази даних, ID процесу, клієнтський хост:номер порта, ID сесії, кількість рядків на сесію, командний тег, час запуску сесії, ID віртуальної транзакції, ID реальної транзакції, перевірка на помилки, код SQL, повідомлення помилок, деталі повідомлення, підказка, внутрішній запит, що призвів до помилки (якщо є такий і включений log_min_error_statement), номер символа, з якого починається помилка, розміщення помилки в вихідному коді, якщо log_error_verbosity встановлений в verbose, і імя додатку. Ось приклад оголошення таблиці для зберігання таких логів:
CREATE TABLE postgres_log
(
log_time timestamp(3) with time zone,
user_name text,
database_name text,
process_id integer,
connection_from text,
session_id text,
session_line_num bigint,
command_tag text,
session_start_time timestamp with time zone,
virtual_transaction_id text,
transaction_id bigint,
error_severity text,
sql_state_code text,
message text,
detail text,
hint text,
internal_query text,
internal_query_pos integer,
context text,
query text,
query_pos integer,
location text,
application_name text,
PRIMARY KEY (session_id, session_line_num)
);
Щоб імпортувати файл логів, використайте команду COPY FROM:
COPY postgres_log FROM ’/full/path/to/logfile.csv’ WITH csv;
Для спрощення імпорту логів CSV вам потрібно значти наступне:
Встановіть log_filename і log_rotation_age щоб забезпечити передбачувану схему найменування файлів. Це дозволить знати, яке імя файлу буде і знати, коли завершиться файл, перед його імпортом.
Встановіть log_rotation_size в 0, щоб відключити ротацію по розмір, тому що це робить імя файлу важким для передбачення.
Встановіть log_truncate_on_rotation в on, щоб старі дані логів не мішалися з новими в одному файлі.
Визначення таблиці вище задає первинний ключ. Це корисно для уникнення імпортуваня однієї інформації двічі. Команда COPY копіює всі дані, тому будь-яка помилка призведе до збою імпорту. Якщо ви імпортуєте окремий файл логів і потім імпортуєте його після того, як він заповнився, дступ до первинного ключа дасть збій. Перед імпортом дочекайтесь заповнення і закриття логу. Ця процедура захищає від випадкового імпорту окремого рядка, який не був дописаний, що також призведе до збою COPY.
18.8. Статистика роботи.
18.8.1. Колектор статистики запитів та індексів.
Ці параметри контролюють збір статистики на сервері. Коли ключений збір статистики, дані, що видаються, можуть бути доступні через pg_stat і pg_statio системні перегляди. Подивіться розділ 27.
track_activities (boolean)
Включає збір інформації на поточній команді, що виконується, на кожній сесії згідно часу, коли ця команда почала виконання. Цей параметр включено по замовчуванню. Зауважте, що навіть коли він включений, ця інформація не є видимою для всіх користувачів, тільки для суперкористувачі і користувача, що є власником сесії, тож це не представляє ризику захисту. Тільки суперкористувачі можуть міняти це значення.
track_activity_query_size (integer)
Задає число байтів, резервованих для поточної команди поточної сесії, для поля pg_stat_activity.current_query. По замовчуванню 1024. Задається при запуску сервера.
track_counts (boolean)
Включає збір статистики по активності бази даних. Цей параметр включений по замовчуванню, оскільки демон автовакууму потребує цієї інформації. Тільки суперкористувачі можуть міняти цю опцію.
track_functions (enum)
Включає запис викликів функцій і часу використання. Задайте pl для запису тільки функцій процедурних мов, all для запису функцій мовами SQL і C. По замовчуванню none, що відключає запис функцій. Тільки суперкористувачі можуть міняти це значення.
Зауваження: функції мовою SQL, які досить прості, щоб записуватись в запит, не будуть записуватись, не дивлячись на цю опцію.
update_process_title (boolean)
Включає оновлення назви процесу кожен раз, коли нова команда SQL отримується сервером. Назва процесу переглядається в ps, а на Windows – диспетчері задач. Тільки суперкористувачі можуть міняти це значення.
stats_temp_directory (string)
Встановлює папку для збереження тимчасових даних статистики в ній. Це може бути відносний шлях директорії даних, або абсолютний шлях. По замовчуванню це pg_stat_tmp. Встановлення цього в файл ОЗП буде зменшувати вимоги до вводу-виводу і збільшувати продуктивність. Цей параметр може задаватись в postgresql.conf або в командному рядку сервера.
18.8.2. Моніторинг статистики.
log_statement_stats (boolean)
log_parser_stats (boolean)
log_planner_stats (boolean)
log_executor_stats (boolean)
Для кожного запиту, виводить статистику виконання в відповідний модуль серверних логів. Це незрілий профільований інструмент, подібний до можливості Unix getrusage().log_statement_stats надає статистику виразів, тоді як інші надають статистику по модулях. log_statement_stats не може бути включеним з модульними опціями одночасно. Всі ці опції відключені по замовчуванню. Тільки суперкористувачі можуть міняти це значення.
18.9. Автоматичний вакуум.
Ці налаштування контролюють поведінку цієї можливості. Дивіться 23.1.5 для більшої інформації.
autovacuum (boolean)
Контролює, чи сервер має запускати демон автовакууму. Включене по замовчуванню, хоча track_counts теж має бути включеним для роботи автовакууму. Цей параметр може задаватись в postgresql.conf або з командного рядка сервера.
Зауважте, що навіть коли цей параметр відключено, система запускатиме процес автовакууму, якщо потрібно запобігти обгортанню ID транзакції. Більше в розділі 23.1.4.
log_autovacuum_min_duration (integer)
Спричиняє запис кожної операції, зробленої автовакуумом, в лог, якщо він працює як мінімум задане число мілісекунд. Значення 0 записує всі дії автовакууму. -1 відключає цю опцію. Для прикладу, якщо ви поставили 250ms, всі автоматичні вакууми, що тримали довше, будуть записані. Включення цього параметру буде корисним для прослідковування активності автовакууму. Цей параметр задається в postgresql.conf або командному рядку сервера.
autovacuum_max_workers (integer)
Задає максимальну кількість процесів автовакууму, які можуть працювати одночасно. По замовчуванню 3. Цей параметр задається при запуску сервера.
autovacuum_naptime (integer)
Задає мінімальну затримку між запуском автовакууму на кожній даній базі даних. В кожному раунді демон перевіряє базу даних і запускає команди VACUUM і ANALYZE для таблиць бази даних. Затримка вимірюється в секундах, по замовчуванню 1 хвилина. Цей параметр задається postgresql.conf або в командному рядку сервера.
autovacuum_vacuum_threshold (integer)
Задає мінімальне число оновлених або видалених кортежів, потрібних для включення VACUUM в будь-якій таблиці. По замовчуванню 50 кортежів. Цей параметр задається в postgresql.conf або командному рядку сервера. Може задаватись для окремих таблиць зміною параметрів збереження.
autovacuum_analyze_threshold (integer)
Задає мінісальну кількість вставлених, оновлених або видалених кортежів для включення ANALYZE для таблиці. Цей параметр задається в postgresql.conf або командному рядку сервера. Може задаватись для окремих таблиць зміною параметрів збереження.
autovacuum_vacuum_scale_factor (floating point)
Задає частку таблиці для додавання, щоб autovacuum_vacuum_threshold вирішив включити VACUUM. По замовчуванню 0.2 (20% розміру таблиці). Цей параметр задається в postgresql.conf або командному рядку сервера. Може задаватись для окремих таблиць зміною параметрів збереження.
autovacuum_analyze_scale_factor (floating point)
задає частку розміру таблиці для додавання, щоб включити ANALYZE. По замовчуванню 0.1. Цей параметр задається в postgresql.conf або командному рядку сервера. Може задаватись для окремих таблиць зміною параметрів збереження.
autovacuum_freeze_max_age (integer)
Задає максимальний вік (у транзакціях), який може мати поле pg_class.relfrozenxid перед запускам операції VACUUM для запобігання перевизначення в таблиці. Зауважте, що чистемі включить прцес автовакууму, навіть якщо він відключений. По замовчуванню 200 мільйонів транзакцій. Цей параметр задається при запуску сервера, але значення може зменшуватись для окремих таблиць установкою параметрів збереження. Дивіться розділ 23.1.4.
autovacuum_vacuum_cost_delay (integer)
Задає затримку ціни, що використовується в автоматичних операціях вакууму. Якщо -1, то буде використовуватись значення vacuum_cost_delay. По замовчуванню 20 мс. Цей параметр задається в файлі postgresql.conf або командному рядку сервера і може перезаписуватись для окремих таблиць зміною опцій зберігання.
autovacuum_vacuum_cost_limit (integer)
Задає значення ціни, яке буде використовуватись для автоматичних операцій вакууму. Якщо -1 (як по замовчуванню), буде використовуватись vacuum_cost_limit. Зауважте що значення роздається всім процесам автовакууму, якщо є більше одного, то сума перевищить ліміт на цю змінну. Цей параметр задається в файлі postgresql.conf або командному рядку сервера і може перезаписуватись для окремих таблиць зміною опцій зберігання.
18.10. Значення по замовчуванню для клієнтських зєднань.
18.10.1. поведінка виразів.
search_path (string)
Ця змінна задає порядок, в якому схеми шукаються, коли обєкт посилається на просте імя без заданої схеми. Коли є обєкти з однаковими іменами в різних схемах, буде використовувати перший знайдений. Обєктт, яккого нема в схемах в шляху пошуку може посилатись тільки з явно заданою схемою, що його містить.
Значення search_path має бути списком схем, розділених комою. Якщо один з пунктів списку є значення $user, тоді схема з іменем, що повертається SESSION_USER заміняється, якщо є така схема (якщо нема, змінна ігнорується).
Схема системного каталогу pg_catalog, завжди шукається, незалежно чи вона була задана, чи ні. Якщо вона згадана в шляху, пошук буде відбуватись у заданому порядку. Якщо pg_catalog нема в шляху він буде шукатись перед пошуком інших пунктів.
Так само схема тимчасової таблиці pg_temp_nnn, також шукається, якщо вона існує. Вона може бути явно задана в шляху, використовуючи аліас pg_temp. Якщо вона не задана в шляху, її шукають першою, навіть перед pg_catalog. Хоча ця схема шукається тільки для звязків і імен типів даних. В ній ніколи не шукаються функції та оператори.
Коли обєкти створюються без задання окремої цільової схеми, вони будуть поміщені в першу схему, перелічену в шляху. Якщо шлях пустий, виникне помилка.
По замовчуванню параметром є ’"$user", public’ (де друга частина ігнорується, якщо схеми public не існує. Це підтримує загальний доступ до бази даних (де користувачі мають власні схеми, і всі користуються public), приватні схеми і їх комбінація. Інші ефекти можуть задаватись зміною шляху пошуку по замовчуванню, глобально або для окремого користувача.
Поточне ефективне значення шляху пошуку може перевіритись через функцію SQL current_schemas(). Це не те саме, що перевірка search_path, оскільки current_schemas() показує, як схеми, що появились search_path були вирішені.
Для детальнішої інформації, дивіться розділ 5.7.
default_tablespace (string)
Ця змінна задає табличний простір по замовчуванню, в якому створюються обєкти, якщо команда CREATE явно не задає цього простору.
Значенням є імя простору або пустий рядок, щоб задати простір, що використовується для поточної бази даних. Якщо значення не відповідає імені існуючого табличного простору, PostgreSQL буде використовувати протір по замовчуванню. Якщо задане інше значення, користувач має мати привілей CREATE для нього, інакше створення провалиться.
Як змінна не використовується для тимчасових таблиць. Для них є temp_tablespaces.
Для решти інформації - розділ 21.6.
temp_tablespaces (string)
Ця змінна задає простір, де створюються тимчасові обєкти ( таблиці та індекси таблиць), коли CREATE не задає цей простір явно. Тимчасові файли для сортування великих масивів даних теж створюються в цих просторах.
Значенням є список імен просторів. Якщо є більше одного члена в списку, PostgreSQL вибере випадковий зі списку. Крім того, в транзакції, створені тимчасові обєкти будуть розміщені в простори зі списку. Якщо вибраний елемент списку – пустий рядок, PostgreSQL вибере простір по замовчуванню для поточної бази даних.
Коли temp_tablespaces задається інтерактивно, задаючи неіснуючий простір, зявляється помілка, так само, як і у випадку, коли користувач не має привілеїв CREATE. Хоче коли використовується значення попереднього списку, неіснуючі простори ігноруються, як і простори, де у користувача не має привілеїв CREATE. Це правило працює, коли значення списку розміщене в postgresql.conf.
По замовчуванню значенням є пустий рядок, що створює всі тимчасові обєкти в просторі поточнох бази даних. Дивіться також default_tablespace.
check_function_bodies (boolean)
Цей параметр зазвичай увімкнено. Коли його виключають, він відключає перевірку рядка функції при CREATEFUNCTION. Це робиться для уникнення проблем типу посилань при відновленні функцій з дампу.
default_transaction_isolation (enum)
Кожна транзакція SQL має рівень ізоляції, який може бути “read uncommitted”, “readcommitted”, “repeatable read”, або “serializable”. Цей параметр контролює значення ізоляції по замовчуванню. По замовчуванню це значення “read committed”.
Дивіться розділ 13 і SETTRANSACTION для детальної інформації.
default_transaction_read_only (boolean)
Транзакція тільки для читання не може змінювати нетимчасові таблиці. Цей параметр контролює статус читання по замовчуванню для кожної нової транзакції. По замовчуванню вимкнено.
Дивіться SETTRANSACTION для детальнішої інформації.
session_replication_role (enum)
Контролює деякі тригери, звязані з реплікацією і правила для поточної сесії. Встановлення цієї змінної вимагає привілеїв суперкористувача і результети в відміні попередньо кешованих планів запитів.
Можливі значення origin (по замовчуванню), replica and local. Дивіться ALTER TABLE для детальної інформації.
statement_timeout (integer)
Відміна виразу, який займає більше, ніж заданий проміжок в мілісекундах, починаючи з часу, коли команда прибуває на сервер з клієнта. Якщо log_min_error_statement встановлений в ERROR або нижче, відмінені вирази будуть записуватись. По замовчуванню значення – 0, що відключає цю функцію.
Встановлення statement_timeout в postgresql.conf не рекомендується, оскільки воно впливає на всі сесії.
vacuum_freeze_table_age (integer)
VACUUM задає сканування всієї таблиці якщо поле таблиці pg_class.relfrozenxid досягло віку, заданого цією сесією. По замовчуванню – 150 млн. транзакцій. Хоча користувачі можуть встановати це значення в будь-яке від 0 до 1000 000 000, VACUUM обмежить це значення до 95% від autovacuum_freeze_max_age, тож вона має шанс запуститись перед антиобгортальним вакуумом для таблиці. Для більшої інформації Розділ 23.1.4.
vacuum_freeze_min_age (integer)
Задає вік в транзакціях, після яких VACUUM і гарячі оновлення включать очищення мертвих версій рядків. По замовчуванню 0, що означає, що такі рядки будуть видалятись якнайшвидше. Ви можете захотіти встановити ненульове значення, коли виконуєте конфігурацію з розділу 25.5. Рекомендоване значення 0, якщо у вас немає причини збільшити його. Призначення цього параметру – дозвіл користувачу задавати приблизний час затримки перед очисткою. Але зауважте, що немає звязку між заданою затримкою результати будуть спецфічні для інсталяції та програми, як і змінна часу, що залежить від рівня транзакції )тільки для запису).
bytea_output (enum)
Задає вихідний формат значень типу bytea. Значеннями може бути hex (по замовчуванню) і escape (традиційний формат для PostgreSQL) Дивіться розділ 8.4. Тип bytea завжди приймає обидва формати вводу, незалежно від установки.
xmlbinary (enum)
Встановлює, як бінарні значення кодуються в XML. Це стосується для прикладу випадку, коли значення bytea конвертуються в XML функціями xmlelement або xmlforest. Можливими значеннями є base64 і hex, які задані в стандарті XML Schema. По замовчуванню base64. Для детальнішої інформації про функції, звязані з XML, дивіться розділ 9.14.
Вибір залежить від смаку, обмежується тільки можливими обмеженнями клієнтських додатків. Обидва методи підтримують всі можливі змінні, хоча hex буде трохи більшим за base64.
xmloption (enum)
Задає DOCUMENT і CONTENT для неявного використання, при конвертації з XML в символьні рядки. Дивіться 8.13 для більшої інформації. Значеннями є DOCUMENT і CONTENT, по замовчуванню вибране друге.
Згідно до стандарту SQL команда для задавання цієї опції:
SET XML OPTION { DOCUMENT | CONTENT };
Цей синтаксис працює і в PostgreSQL.
18.10.2. Локалізація і форматування.
DateStyle (string)
Задає формат виводу значень дати і часу, і правила інтерпретації вводу дати. По історичних причинах, ця змінна має два незалежні компоненти: специфікацію формату: (ISO, Postgres, SQL, або German) і специфікацію вводу-виводу дати (DMY, MDY, або YMD). Вони можуть задаватись разом або окремо. Слова Euro і European є синонімами DMY; слова US, NonEuro і NonEuropean є синонімами MDY. Дивіться розділ 8.5 для більшої інформації. Вбудованими по замовчуванню є ISO, MDY але initdb буде ініціалізувати файл конфігурації з опцією, що відповідає поведінці локації lc_time.
IntervalStyle (enum)
Задає формат виводу інтервалів. Значення sql_standard буде давати вихід, що відповідає стандартам виводу інтервалів SQL. Значення postgres (по замовчуванню) буде давати вивід, що відповідає релізам PostgreSQL до версії 8.4, де параметр DateStyle був встановлений в ISO.
Значення postgres_verbose буде давани вивід PostgreSQL версій до 8.4, де DateStyle був заданий на вивід не- ISO. Значення iso_8601 дасть вивід, що відповідає формату “format with designators”, визначеного в розділі 2.2.3.2 ISO 8601.
Параметр IntervalStyle вспливає на інтерпретацію вводу часових інтервалів. Дивіться Розділ 8.5.4 для детальніших даних.
timezone (string)
Задає часову зану для виведення та інтерпретації часу. По замовчуванню unknown, що означає використання системної змінної, що задає часовий пояс. Дивіться розділ 8.5.3 для деталей.
timezone_abbreviations (string)
Задає колекцію абревіатур часових зон, що сприймаються сервером для вводу дати і часу. По замовчуванню ’Default’, це колеція що працює в світі. Є також ’Australia’ та ’India’, та інші колекції можуть задаватись для окремої інсталяції. Дивіться додаток В для інформації.
extra_float_digits (integer)
Цей параметр задає формат чисел, що виводять числа з плаваючою комою, включаючи float4, float8, та геометричні типи даних. Значення параметру додається до стандартного числа цифр (FLT_DIG або DBL_DIG відповідно). Значення може бути задано до 3, щоб включити частково значимі цифри. Це корисно для дампування даних, які мають виводитись точно. Або може задаватись відємним для забирання непотрібних цифр.
client_encoding (string)
Задає шифрування зі сторони клієнта. По замовчування використовується шифрування бази даних.
lc_messages (string)
Задає мову, на якій виводяться повідомлення. Прийнятні значення залежать від системи, дивіться Розділ 22.1. Якщо ця змінна – пустий рядок (як по замовчуванню), значення буде успадковане із середовизще сервера, залежно від системи.
На деяких системах, ця категорія не існує. Встановлення змінної працює, але воно не дає нічого. Є також шанс, що немає перекладених повідомлень для заданої мови. В цьому випадку ви будете бачити повідомлення англійською.
Тільки суперкористувачі можуть міняти це значення, оскільки воно впливає на пвідомлення, що відправляються в лог сервера і клієнта, тож це вплине на читабельність логів сервера.
lc_monetary (string)
Задає локацію для форматування грошових одиниць. Для прикладу сімейством функцій to_char. Прийнятні значення залежать від системи, дивіться 22.1 для детальнішої інформації. Якщо ця змінна задана як пустий рядок, значення успадковується від середовища сервера в залежності від системи.
lc_numeric (string)
Встановлює локацію для використання форматування чисел. Для прикладу сімейства функцій to_char. Прийнятні значення залежать від системи, дивіться 22.1 для детальнішої інформації. Якщо ця змінна задана як пустий рядок, значення успадковується від середовища сервера в залежності від системи.
lc_time (string)
Задає локацію для форматування дати і часу. Для прикладу сімейством функцій to_char. Прийнятні значення залежать від системи, дивіться 22.1 для детальнішої інформації. Якщо ця змінна задана як пустий рядок, значення успадковується від середовища сервера в залежності від системи.
default_text_search_config (string)
Вибирає конфігурацію пошуку тексту, що використовується варіантами функції пошуку тексту, що не мають явного аргумента, що задає конфігурацію. Дивіться розділ 12 для подальшої інформації. Вбудованим значенням по замовчуванню є pg_catalog.simple, або initdb ініціалізує файл конфігурації, відповідний локації lc_ctype, якщо ця конфігурація може бути ідентифікована.
18.10.3. Інші значення по замовчуванню.
dynamic_library_path (string)
Якщо динамічно завантажуваний модуль має відкриватись, і імя файлу, задане в CREATE FUNCTION або LOAD не має компоненту каталога (тобто імя не містить слеш), система буде шукати потрібний файл у цьому каталозі.
Значення dynamic_library_path має бути переліком абсолютних шляхів, розділених двокрапкою (крапкою з комою для Віндовс). Якщо елемент починається з рядка $libdir, його заміняється каталогом бібліотек пакетів PostgreSQL. Це модулі, що задаються зі стандартного дистрибутиву PostgreSQL. (Використовуйте pg_config –pkglibdir, щоб знайти імя цього каталогу). Для прикладу
dynamic_library_path = ’/usr/local/lib/postgresql:/home/my_project/lib:$libdir’,
або в середовищі Віндовс
dynamic_library_path = ’C:\tools\postgresql;H:\my_project\lib;$libdir’
По замовчуванню цей параметр має значення ’$libdir’. Якщо значення є пустим рядком, пошук по шляхам буде відключеним.
Цей параметр має мінятись під час роботи суперкористувачами, але опція встановиться тільки після закриття зєднання, тож цей метод використовується для розробки. Рекомендованим шляхом встановлення параметру є файл postgresql.conf.
gin_fuzzy_search_limit (integer)
Верхня межа розміру набору, що повертається скануванням індексів GIN. Для детальнішої інформації дивіться розділ 53.4.
local_preload_libraries (string)
Ця зміння задає одну або більше бібліотек загального доступу, які мають завантажуватись на початку зєднання. Їх розділяють комами. Цей параметр не може встановлючатись після початку сесії.
Оскільки це не є опцією суперкористувачів, бібліотеки,що можуть завантажуватись, обмежуються встановленими в plugins і стандартний каталог бібліотек. (Впевненість у вмісті цих каталогів на совісті адміністратора бази даних). local_preload_libraries може задати цей каталог явно, для прикладу $libdir/plugins/mylib, або просто задайте імя бібліотеки mylib, що буде мати той самий ефект, що й $libdir/plugins/mylib.
На відміну від local_preload_libraries, немає переваги виконання завантаження бібліотеки при запуску сесії, як і при першому використанні. Призначенням цієї опції є дозвіл відлагодження потрібних бібліотек для завантаження в потрібні сесії баз явної команди LOAD. Для прикладу, відладка може бути включена для всіх сесіях під заданим іменем користувача, встановленням параметра з допомогою ALTER USER SET.
Якщо потрібна бібліотека не знайдеться, зєднання не встановиться.
Кожна біблаотека, що підтримується PostgreSQL, має магічний блок, що перевіряється для гарантії сумісності. Тому бібліотеки, що не належать до PostgreSQL подібним чином завантажувати не можна.
18.11. Керування замками.
deadlock_timeout (integer)
Проміжок часу в мілісекундах, на очікування замка перед перевіркою, чи немає умови блокування. Ця перевірка відносно дорога, тому кожен раз її запускати не можна. Ви оптимістино припускаємо, що взаємоблокування не є звичним для додатків і потрібно почекати на замок перед перевіркою на блокування. Збільшення цього значення зменшує час, потрачений на перевірку блокування, але сповільнює звіти про блокування. По замовчуванню 1 секунда, що напевно є найменшим значенням, що використовується на практиці. На дуже завантаженому сервері ви можете захотіти підвищити його. Ідеально ці значення має перевищувати час типової транзакції, тож це дасть впевненість, що замок буде звільнений до перевірки блокування.
Коли встановлено log_lock_waits цей параметр також задає час, який треба почекати, щоб було виведено повідомлення логу про очікування замка. Якщо ви пробуєте міняти ці затримки, вам потрібно встановлювати їх коротшими за deadlock_timeout.
max_locks_per_transaction (integer)
Таблиця замків перевіряє max_locks_per_transaction * (max_connections + max_prepared_transactions) обєкти (наприклад, таблиці). Не більше, ніж ця кількість обєктів можуть мати замок одночасно. Цей параметр контролює середню кількість обєктних замків для однієї транзакції, індивідуальні транзакції можуть накладати замки на більше обєктів, оскільки замки для всіх транзакцій вкладаються в таблицю. Це не є числом закритих рядків – це значення необмежене. По замовчуванню значення 64 визначно ефективним, але вам може понадобитись збільшити це значення, якщо ви маєте клієнтів з багаться різними таблицями для однієї транзакції. Цей параметр задається при запуску сервера.
Його збільшення призведе до запиту більшої кількості памяті загального доступу, ніж дозволяє конфігурація операційної системи. Дивіться розділ 17.4.1 для установки цих параметрів.
Коли запускаєте резервний сервер, ви маєте встановити цей параметр таким же, або вищим ніж на сервері мастера. Інакше на цьому сервері не будуть дозволені запити.
18.12. Сумісність версій та платформ.
18.12.1. попередні версії PostgreSQL
array_nulls (boolean)
Цей параметр контролює чи ввід в масив розпізнає NULL без апострофів як задання нульового значення елемента. По замовчуванню включено, дозволяє ввід нульових значень. Але версії до 8.2 не підтримують нульові елементи в масиві, що задасть запис NULL як нормальний елемент з рядковим значенням NULL. Для сумісності зі старими версіями, параметр має бути вимкненим.
Зауважте, що моажливо створювати значення, що мають нульові значення навіть з виключеною опцією.
backslash_quote (enum)
Контролює, коли знак апострофа може задаватись літералом \’ Стандартом SQL є задання цього знака подвійними лапками, але в PostgreSQL історично прийняте \’. Хоче це ризиковано, оскільки частина літерала може сприйматись як символ ASCII \. Якщо код клієнта працює некоректно, можлива атака SQL-інєкціями. Цей ризик уникається відкиданням запитів, в яких є апостроф, що супроводжується бекслешем. Дозволеними значеннями є on (дозволяє), off ( відкидає), і safe_encoding (дозволяє, якщо кодування клієнта не дозволяє ASCII \ в багатобайтному символі). safe_encoding встановлене по замовчуванню.
Зауважте, що стандартний літерал \ означає \. Цей параметр впливає тільки на нестандартні літерали, включаючи синтаксис рядка (E’...’).
default_with_oids (boolean)
Цей параметр контролює, коли CREATE TABLE і CREATE TABLE AS включають стовпчик OID у новостворені таблиці, якщо не задано WITH OIDS чи WITHOUT OIDS. Він також задає, чи буде включено OID в таблиці, створені SELECT INTO. Параметр виключений по замовчуванню, але в версіях до 8.0. і раніших він був включений по замовчуванн.
Використання OID в користувацьких таблицях непотрібне, тож більшість інсталяцій не включаються його. Додатки, що вимагають OID для таблиці, мають задавати OIDS при створенні таблиці. Ця змінна може включатись для сусмісності зі старими версіями, що не мають такої поведінки.
escape_string_warning (boolean)
Коли включене, попередження виникає при виникненні (\) в рядковому літералі (синтаксис ’...’) і standard_conforming_strings вимкнено. По замовчуванню включене.
Додатки, що хочуть використовувати бекслеш мають бути модифіковані для використання синтаксису (E’...’), оскільки поведінка по замовчуванню змінить сумісність SQL. Ця змінна може бути включена для пошуку додатків, що перериваються.
lo_compat_privileges (boolean)
В релізах PostgreSQL до 9.0 великі обєкти не мали привілеїв доступу і були доступні для читання та запису для всіх користувачів. Ввімкнення відключає нові перевірки привілеїв, для сумісності з попередніми версіями. По замовчуванню вимкнено.
Встановлення цієї змінної не відключає захист для великих обєктів тільки для тих, в яких поведінка була змінена в PostgreSQL9.0. Для прикладу lo_import() і lo_export() потребують привілеїв суперкористувача незалежно від цієї опції.
sql_inheritance (boolean)
Контролює семантику успадкування. Якщо вимкнено, підтаблиці недоступні для різних команд по замовчуванню. Використовується ключове слово ONLY. Це було додатно для сумісності з версіями до 7.1. Дивіться розділ 5.8 для детальнішої інформації.
standard_conforming_strings (boolean)
Контролює, чи стандартні рядкові літерали (’...’) перевіряють бекслеш літерально, як задано в стандарті SQL. По замовчуванню вимкнено, тобто включена підтримка бекслешів як службових символів. Додатки можуть задавати те, як буде оброблятись літерал. Цей параметр також показує, чи пітримується синтаксис (E’...’). цей синтаксис (Section 4.1.2.2) має використовуватись для того, щоб бекслеші рахувались службовими символами.
synchronize_seqscans (boolean)
Це дозволяє похідні сканування великих таблиць для синхронізації одних з одними, тож ці сканування читають блок одночасно і розподіляють навантаження вводу-виводу. Коли воно включено, скорування почнеться з середнини таблиці і потім буде обгортатись до кінця, щоб покрити всі рядки, тож це синхронізується з активністю сканувань, що відбуваються. Це може дати непередбачувані зміни в порядку рядків, що повертаються запитами, що не мають уточнення ORDER BY. Вимкнення цього параметра задає поведінку до версії 8.3, в якій сканування починається з початку таблиці. По замовчуванню ввімкнено.
18.12.2. Сумісність платформ і клієнтів.
transform_null_equals (boolean)
Коли включено вирази форми expr = NULL або NULL = expr передаються як expr IS NULL,, пони повертають true, якщо expr посилається на значення null, а інакше – false. Коректною поведнікою, узгодженою з SQL для expr = NULL є повернення null. Цей параметр по замовчуванню вимкнено.
Але відсотовані форми в Microsoft Access генерують запити, які використовують expr = NULL для перевірки нульових значень, тож якщо ви використовуєте цей інтерфейс для бази даних, ви можете включити цю опцію. Оскільки вирази expr = NULL завжди повертають значення null, вони не є чимось корисним і нечасто появляються в додатках, тож ця опція мало дає на практиці. Але нові користувачі часто здивовані семантикою виразів, що включаються значення null, тому ця опція відключена по замовчуванню.
Зауважте, що ця опція впливає тільки на форму = NULL, ні на які інші оператори порівняння або інші вирази, що еквівалентнів виразам, що мають оператор рівності (наприклад IN). Ця опція не є рішенням проти поганого програмування.
Більше про це в Розділі 9.2.
18.13. Попередні опції.
Наступні параметри доступні тільки для зчитування і визначені при компіляції та установці PostgreSQL. Вони виключені з файлу postgresql.conf . Ці опції дають інформацю про різні аспекти поведніки PostgreSQL, що може бути потрібним деяким додатким, особливо адміністративним формам.
block_size (integer)
Розмір блоку диска. Задається значенням BLCKSZ при побудові сервера. По замовчуванню 8 Кб. Значення деяких змінних конфігурації визначається block_size. Більше в розділі 18.4.
integer_datetimes (boolean)
Показує, чи був побудований PostgreSQL с підтримкою 64-бітної дати і часу. Це може бути відключеним при побудові PosgreSQL опцією --disable-integer-datetimes. По замовчуванню включено.
lc_collate (string)
задає локалізацію сортування текстових даних. Дивіться в розділі 22.1. Це значення задається при створенні бази даних.
lc_ctype (string)
Задає Локацію, що визначає класифікацію символів. Дивітьс Розділ 22.1. Це значення задається при створенні бази даних. Воно буде таким же, як і lc_collate, але для деяких додатків може відрізнятись.
max_function_args (integer)
Задає максимальну кількість аргументів функції. Задається значенням FUNC_MAX_ARGS при побудові сервера. По замовчуванню 100 аргументів.
max_identifier_length (integer)
Задає максимальну довжину ідентифікатора. Визначається значенням меншим на одиницю від NAMEDATALEN. По замовчуванню значення для NAMEDATALEN є 64, тож max_identifier_length дорівнює 63, але буде меншим при використанні багатобайтного кодування символів.
max_index_keys (integer)
Задає максимальну кількість ключів індексів. Задається при побудові сервера в INDEX_MAX_KEYS. По замовчуванню 32.
segment_size (integer)
Кількість блоків (сторінок) всередині сегменту файлу. Задається значенням RELSEG_SIZE при побудові сервера. Максимальне значення рівне добутку segment_size і block_size; по замовчуванню 1 Гб
server_encoding (string)
Шифрування бази даних. Задається при ствоенні бази даних. Клієнтам сає бути відоме тільки значення client_encoding.
server_version (string)
Номер версії сервера. Задається значенням PG_VERSION при побудові сервера.
server_version_num (integer)
Задає номер версії сервера як ціле число. Задається як PG_VERSION_NUM при побудові сервера.
wal_block_size (integer)
Задає розмір блоку диску WAL. Задається при побудові сервера змінною XLOG_BLCKSZ. По замовчуванню 8 Кб.
wal_segment_size (integer)
Задає кількість блоків в файлі сегменту WAL. Загальний розмір файлу рівний добутку wal_segment_size на wal_block_size; по замовчуванню 16 Мб. Більше в розділі 29.4.
18.14. Клієнтські опції.
Ця можливіть задана, щоб дозволяти параметри, що невідомі для додавання в модулі PostgreSQL. Це дозволяє конфігурувати модулі стандартним шляхом.
custom_variable_classes (string)
Ця змінна задає одне з декількох імен клау, що використовується для клієнтських змінних, в формі списку, розділеного комами. Це змінні, які невідомі PostgreSQL, але використовуються в деяких модулях. Такі змінні мають мати імя, що складається з імені класу, крапки, імені змінної. custom_variable_classes задає всі імена класів для цієї установки. Цей параметр задається в файлі postgresql.conf або командному рядку сервера.
Складність задання таких змінних в postgresql.conf в тому, що файл читається перед завантаженням модулів, і ці змінні будуть відкинуті як невідомі.
Коли custom_variable_classes задається, сервер приймає визначенні змінних для кожного заданого класу. Ці змінні будуть відомі як комірки зі значеннями, поки не завантажиться модуль, що визначає їх. Коли завантажується модуль окремого класу, від додасть потрібні визначення для цього імені класу, конвертує комірки згідно оголошення і видасть попередження про нерозпізнані комірки для цього класу.
Ось приклад , що має містити файл postgresql.conf при використанні клієнтських змінних.
custom_variable_classes = ’plpgsql,plperl’
plpgsql.variable_conflict = use_variable
plperl.use_strict = true
plruby.use_strict = true # generates error: unknown class name
18.5. Опції розробника
Наступні параметри використовуються для роботи з вихідним кодом PostgreSQL і для допомоги у відновленні пошкоджених баз даних. Нема причини використовувати їх в готовій базі даних. Вони забираються із файлу postgresql.conf. Зауважте, що багато з цих параметрів вимагають спеціальних флагів компіляції для роботи взагалі.
allow_system_table_mods (boolean)
Дозволяє модифікацію структури системних таблиць. Використовується в initdb. Цей параметр може задаватись при запуску сервера.
debug_assertions (boolean)
Включає перевірку різних припущень. Це допомога в відладці. Якщо ви маєте різні проблеми і помилка, ви можете це включити, бо це покаже деякі помилки програми. Щоб використати ці параметри, має бути визначений USE_ASSERT_CHECKING при побудові PostgreSQL (або опція configure --enable-cassert). Зауважте, що debug_assertions включений, якщо PostgreSQL будувався з включеними припущеннями.
ignore_system_indexes (boolean)
Ігнорує системні індекси при читанні системних таблиць (але оновлює індекси при модифікації таблиць). Це корисно для відновлення пошкоджених системних індексів. Не може мінятись після початку сесії.
post_auth_delay (integer)
Ненульове значення визначає кількість секунд перед стартом нового процесу сервера після проведення аутентифікації. Це дає можливість розробникам приєднувати серверний процес до відладника. Цей параметр не можна змінювати після початку сесії.
pre_auth_delay (integer)
Ненульове значення задає затримку після відгалуження серверного процесу перед тим, як він пройде процедуру аутентифікації. Це дає можливість розробникам приєднувати серверний процес до відладника для виявлення неправильної поведінки при аутентифікації. Цей параметр задається в postgresql.conf або командному рядку сервера.
trace_notify (boolean)
генерує вивід відладника для команд LISTEN і NOTIFY. client_min_messages або log_min_messages мають бути рівня DEBUG1 або нижче для відсилання цього виводу в логи клієнта та сервера відповідно.
trace_sort (boolean)
Якщо включено, показує інформацію використання ресурсів при сортуванні. Цей параметр доступний, якщо при компіляції PostgreSQL був встановлений TRACE_SORT. (хоча зараз це робиться за замовчуванням).
trace_locks (boolean)
Якщо опція увімкнена, видає інформацію про використання замків. Інформація включає тип операції замка, тип замка та ідентифікатор обєкта, на який наклали або зняли замок. Також включені маски біті для замків цього обєкту як і для типу замків у цьому обєкті. Для кожного типу замка кількість заданих заміків та очікуючих замків також записується. Приклад виводу файлу логів:
LOG: LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1) grantMask(0)
req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0wait(0) type(AccessShareLock)
LOG:GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)grantMask(2) req(1,0,0,0,0,0,0)=1
grant(1,0,0,0,0,0,0)=1wait(0) type(AccessShareLock)
LOG: UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1) grantMask(0)
req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0wait(0) type(AccessShareLock)
LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1) grantMask(0)
req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0wait(0) type(INVALID)
Деталі структури дампу шукайте на src/include/storage/lock.h
Цей параметр доступний з включеним LOCK_DEBUG при компіляції PostgreSQL
trace_lwlocks (boolean)
Якщо включений, виводить інформацію про легкі замки, що використовуються для забезпечення спільного доступу до структур даних. Цей параметр доступний з включеним LOCK_DEBUG при компіляції PostgreSQL .
trace_userlocks (boolean)
Якщо включений, виводить інформацію про використання замків користувача. Вивід буде тим же, що й для trace_locks, але для замків користувача.
Замки користувача видалені з версії 8.2. Ця опція зараз не діє.
Цей параметр доступний з включеним LOCK_DEBUG при компіляції PostgreSQL .
trace_lock_oidmin (integer)
Якщо встановлений, не трасуються замки після цього OID. (використовується для уникнення виводу системних таблиць).
Цей параметр доступний з включеним LOCK_DEBUG при компіляції PostgreSQL .
trace_lock_table (integer)
Безумовне трасування замків на даній таблиці (OID).
Цей параметр доступний з включеним LOCK_DEBUG при компіляції PostgreSQL .
debug_deadlocks (boolean)
Якщо включений,дампує інформацію про поточні замки при виникненні DeadLockTimeout
Цей параметр доступний з включеним LOCK_DEBUG при компіляції PostgreSQL .
log_btree_build_stats (boolean)
Якщо включений, записує використання системних ресурсів (пам'ять і процесор) в різні оператори btree.
Цей параметр доступний з включеним LOCK_DEBUG при компіляції PostgreSQL .
wal_debug (boolean)
Якщо включений, видає вивід відладки WAL. Цей параметр доступний з включеним WAL_DEBUG при компіляції PostgreSQL .
trace_recovery_messages (enum)
Контролює рівні повідомлень, що записуються в лог сервера для модулів системи для відновлення. Це дозволяє користувачу перевизначати нольмальні значення log_min_messages, але ля окремих значень. Це потрібно в відладці Hot Standby. Значеннями є DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, і PANIC. Кожен рівень включає всі рівні, що слідують йому. Чим вищий рівень, тим менше повідомлень записується. По замовчуванню WARNING. Зауважте, що LOG має інший рівень, ніж в client_min_messages. Параметр задається в файлі postgresql.conf
zero_damaged_pages (boolean)
Виявлення пошкоджених сторінок викликає звіт про помилку і відміну поточної команди. Встновлення zero_damaged_pages заставляє систему присилати тільки попередження, обнуляти сторінку і продовжувати роботу. Це знищить дані, всі рядки пошкодженої сторінки. Але це дозволить пройти помилку і отримати рядки з цілих сторіно, що є в таблиці. Це корисно при відновленні даних після помилки апаратного чи програмного забезпечення. Ви не маєте задавати цей параметр, якщо у вас є надія відновити дані з пошкоджених сторінок. Значення по замовчуванню – вимкнене і може мінятись тільки суперкористувачем.
18.16. Короткі опції.
Для зручності є однолітерні опції командного рядка для роботи з деякими параметрами. Вони описані в таблиці 18-2. Деякі з цих опцій існують з історичних причин і їх право на однолітерне позначення не означає їх важливість.