Пока турбопатриоты рассказывали про аналоговнетные форки postgresql, и миллионы проверяющих глаз, к нему вышло срочное внепланое обновление для обновления
The PostgreSQL Global Development Group is planning for an out-of-cycle release on February 26, 2026 due to regressions introduced in the February 12, 2026 update release, which included releases 18.2, 17.8, 16.12, 15.16, and 14.21. This release will provide fixes for all supported versions (18.3, 17.9, 16.13, 15.17, 14.22). While these fixes may not impact all PostgreSQL users, the PostgreSQL Global Development Group wants to address these issues before the next scheduled release on May 14, 2026.
PostgreSQL missing validation of multibyte character length executes arbitrary code
Missing validation of multibyte character length in PostgreSQL text manipulation allows a database user to issue crafted queries that achieve a buffer overrun. That suffices to execute arbitrary code as the operating system user running the database. Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected. Overall Score 8.8
Очередная иллюстрация -ЛЮБОЙ ответ нейросетей необходимо экспериментально проверять.
В случае использования советов нейросетей - древняя мудрость особенно актуальна.
Вопрос DeepSeek
Как изменится производительность СУБД PostgreSQL при нагрузке создаваемой pgbench и количестве подключений от 5 до 100 для СУБД размером 300MB при ресурсах CPU = 2 и RAM = 2GB при изменении настроек автовакуума с настроек по умолчанию на агрессивные настройки ?
Ответ DeepSeek
Исходные параметры:
Размер БД: 300 MB
Ресурсы: 2 CPU, 2 GB RAM
Количество подключений: 5–100
Нагрузка: pgbench в режиме TPC-B (смесь SELECT/UPDATE).
Сравнение: Настройки по умолчанию:
autovacuum_vacuum_scale_factor = 0.2
autovacuum_vacuum_threshold = 50
autovacuum_vacuum_cost_delay = 20ms
autovacuum_vacuum_cost_limit = 200
Агрессивные настройки:
autovacuum_vacuum_scale_factor = 0.05 # Запуск при 5% изменений вместо 20%
autovacuum_vacuum_threshold = 25 # Нижний порог срабатывания
autovacuum_vacuum_cost_delay = 5ms # Меньшая задержка между операциями
autovacuum_vacuum_cost_limit = 1000 # Больше операций за один проход
Прогнозируемые результаты:
1. Низкая нагрузка (5–20 подключений):
По умолчанию: Автовакуум запускается редко. Мертвые кортежи накапливаются, но не критично. Производительность стабильна. TPS: ~600–800.
Агрессивные настройки: Автовакуум срабатывает чаще, но нагрузка от него незначительна. Мертвые кортежи удаляются своевременно. TPS: ~650–850 (+5–10%).
2. Средняя нагрузка (30–60 подключений):
По умолчанию: Накопление мертвых кортежей приводит к: Увеличению размера таблиц (из-за "раздувания"). Замедлению SELECT (сканирование большего объема данных). Блокировкам при UPDATE из-за долгих вакуумных операций. TPS: падение до 400–500.
Агрессивные настройки: Частые, но короткие вакуум-сессии. Меньше "раздувания", быстрее доступ к данным. TPS: ~550–700 (+20–40%).
3. Высокая нагрузка (80–100 подключений):
По умолчанию: Критическое накопление мертвых кортежей. Автовакуум не успевает очищать данные, что вызывает: Резкое падение TPS (до 200–300). Рост времени отклика (блокировки, конкуренция за I/O).
Агрессивные настройки: Плюсы: Минимизация "раздувания", стабильный TPS (~450–600). Минусы: Конкуренция за ресурсы CPU между фоновым вакуумом и рабочими процессами. При 2 CPU возможны просадки из-за нехватки вычислительной мощности.
Ключевые метрики для сравнения:
TPS (Transactions Per Second): Агрессивные настройки дадут прирост на 20–40% при 30–60 подключениях. При 80–100 подключениях рост TPS будет менее значительным (+10–15%) из-за ограничений CPU.
Задержки (Latency): В агрессивном режиме задержки будут стабильнее, особенно в диапазоне 30–60 подключений.
Размер таблиц (Table Bloat): Агрессивный автовакуум уменьшит "раздувание" на 40–60% по сравнению с настройками по умолчанию.
Использование CPU: При агрессивных настройках нагрузка на CPU вырастет на 15–25% из-за частого выполнения вакуума.
Рекомендации:
Для тестовой конфигурации (2 CPU, 2 GB RAM): Агрессивные настройки целесообразны при 20–60 подключениях. При 80–100 подключениях требуется мониторинг CPU: если загрузка достигнет 90–100%, производительность может ухудшиться.
Оптимизация под высокую нагрузку: Увеличьте autovacuum_max_workers (если нужно параллелить вакуум). Настройте maintenance_work_mem (выделите 256–512 MB для операций вакуума).
Дисковый I/O: Если диск медленный (HDD), агрессивный автовакуум может вызвать contention I/O. Используйте SSD для минимизации рисков.
Заключение:
Агрессивные настройки автовакуума улучшат производительность на 20–40% при 30–60 подключениях, предотвращая "раздувание" таблиц. Однако при экстремальной нагрузке (80–100 подключений) и ограниченных ресурсах CPU (2 ядра) возможна конкуренция за процессорное время, что снизит эффективность. Тестирование на реальной инфраструктуре с мониторингом CPU/I/O обязательно.
Результаты сравнительных экспериментов
Конфигурация виртуальной машины
CPU = 2RAM = 2GB
Версия СУБД:Postgres Pro (enterprise certified) 15.8.1 on x86_64-pc-linux-gnu, compiled by gcc (AstraLinuxSE 8.3.0-6) 8.3.0, 64-bit
Предлагаю ещё одну задачу по базам данных со своего Телеграм-канала по SQL и базам данных. Итак, среди прочих, имеется таблица выставленных счетов INVOICES:
В некотором отчёте АБС количество счетов, выставленных за текущий день формируется SQL запросом:
SELECT COUNT(*) COUNT_INV FROM INVOICES WHERE DATE(DATE_CREATE) = CURRENT_DATE
Я удивляюсь, как создатели этой конференции каждый год умудряются делать такой профессиональный праздник. Перезагрузка мозга и прямо лечебное общение с коллегами. Профессиональный санаторий какой-то. Пусть эта музыка будет вечной. В этом году как-то особенно душевно получилось.
Продолжаю тему разборов задач с собеседований по SQL. В этот раз выложу полное содержание, чтобы пост не удалили.
Итак, в базе данных есть таблица CLIENTS, содержащая три строки:
И есть таблица INVOICES, в которой две строки:
И сама задача звучит так: какое количество строк вернёт указанный ниже запрос:
SELECT * FROM CLIENTS WHERE EXISTS (SELECT COUNT(*) FROM INVOICES WHERE ID_CLIENT = CLIENTS.ID)
Какой бы вариант Вы выбрали?
Здесь нужно было заметить неправильное использование EXISTS.
Оператор EXISTS используют для проверки того, возвращается ли что-то подзапросом, указанным в скобках. Как правило, в скобках для оператора EXISTS/NOT EXISTS пишут:
SELECT *
или:
SELECT 1
В задаче выше нарочно допущена ошибка (в EXISTS нарочно написано SELECT COUNT).
SELECT COUNT всегда будет возвращать данные. Написанный в скобочках подзапрос всегда будет возвращать количество, хоть и иногда 0. Но данные-то есть. Ноль - это тоже данные. Поэтому EXISTS будет давать TRUE для каждой из трех строчек основного запроса.
Question: What value will the following query return?
SELECT COUNT(*) FROM TMP_TABLE;
Answer:
To determine the result of the query SELECT COUNT(*) FROM TMP_TABLE;, we need to understand what the COUNT(*) function does in SQL. The COUNT(*) function counts the number of rows in a table, regardless of whether they contain NULL values or not.
Let's look at the data in the table TMP_TABLE:
column1column21212NULL131214NULLNULL1315
There are 5 rows in the table. The COUNT(*) function will count all these rows, including those with NULL values.
Therefore, the query:
SELECT COUNT(*) FROM TMP_TABLE;
will return the value 5.
This value is the total number of rows in the table TMP_TABLE, without any consideration of the content of the columns or whether they contain NULL values. ______ ChatGPT4o. Простите.
