Недавно мы писали про новинки сентябрьского и октябрьского релизов Greenplum 6.22, а 18 ноября 2022 года вышла новая отладочная версия, которая решает некоторые проблемы с сервером СУБД, обработкой запросов и потоком данных. Разбираемся, что стало лучше в VMware Tanzu Greenplum 6.22.2 с точки зрения администратора кластера и дата-инженера.
Новинки и исправления в Greenplum 6.22.2
В сервере Greenplum 6.22.2 решены следующие проблемы:
- исправлена ошибка, из-за которой обработка узлов приводила к повреждению памяти и ошибкам PANIC;
- устранена проблема, из-за которой команда создания индекса CREATE INDEX для таблицы только для добавления данных (Append Only, AO) зависала, если к той же таблице выполнялась ранее существовавшая транзакция только для чтения;
- ликвидирована причина, из-за которой происходил сбой ключевого внутреннего процесса при слишком большом количестве одновременных подключений к базе данных;
- решена проблема, из-за которой происходило повреждение памяти после команды очистки VACUUM из-за неправильной инициализации внутренней структуры данных;
- исправлена ситуация, из-за которой запросы удаления данных DELETE FROM из вспомогательных AO-таблиц выдавали ошибку;
- решена проблема с утилитой создания дампов pg_dump, из-за которой во время операций копирования gpcopy внешние конечные таблицы копировались как таблицы кучи вместо внешних таблиц;
- устранена проблема, из-за которой база данных Greenplum могла отбрасывать пакеты и генерировать ошибки межсоединения из-за неправильной логики вытеснения кэша при отключении удаленного однорангового узла;
- исправлена ошибка, из-за которой Greenplum потребляла слишком большое количество памяти при обработке таблиц, ориентированных на столбцы, с большим количеством разделов;
- устранены утечки памяти, связанные с динамическим сканированием растровых изображений в таблицах, ориентированных на столбцы;
- решена проблема с производительностью, которая возникала, когда база данных Greenplum планировала запрос, который включал подвыборку, содержащую группировку строк GROUP BY;
- устранена проблема, из-за которой вызов утилиты pg_upgrade завершался со сбоем при восстановлении внешней таблицы с удаленными столбцами;
- исправлена проблема, из-за которой возникала ошибка PANIC после попытки разделить раздел на новый и раздел по умолчанию в таблице, не имеющей раздела по умолчанию;
- ликвидирована причина, из-за которой запуск внутренней функции в таблице разделов приводил к сбою основного экземпляра базы данных Greenplum;
- устранена проблема, появившаяся в Greenplum21.0, из-за которой возникала ошибки PANIC, XX000 и непредвиденная внутренняя ошибка, когда главный процесс получал сигнал SIGSEGV после выполнения запроса, включающего неподдерживаемую функцию;
- решена проблема, из-за которой моментальный снимок нельзя было импортировать из-за отсутствия метки времени, что влияло на его видимость;
- устранена проблема, из-за которой Greenplum возвращала оператор ошибки 37, не являющийся допустимым оператором упорядочения, поскольку он неправильно генерировал оператор сортировки и оператор равенства, когда типы данных левого и правого операнда различались;
- устранено предупреждение компиляции путем замены вызова strncpy() на вызов memcpy().
Относительно обработки SQL-запросов исправлена проблема, из-за которой оптимизатор GPORCA возвращался к планировщику для запросов, имеющих пересечение битовых значений, если один из битовых векторов был пустой, т.е. имел размер 0. Теперь GPORCA правильно удаляет пустой вектор и создает корректный план SQL-запроса. Также исправлена другая ошибка оптимизатора GPORCA из-за которой он не создавал план производительности, когда запрос включал N-арное соединение только с внутренними соединениями, а предикат был ложным.
Устранен сбой, который мог возникнуть во время планирования запросов для определенных запросов UNION, если выходной столбец для первого дочернего элемента UNION был удален в проекции, что делало статистику столбца недоступной. Также ликвидирована причина, из-за которой GPORCA не выполняла прямую отправку при фильтрации gp_segment_id по ограничениям соединения.
Оптимизатор GPORCA теперь создает более производительный план запроса для SQL-запросов, в которых он может распространять предикат из любого скалярного подзапроса во внешнее отношение. Исправлена регрессия в совместимости с PostGIS, которая вызывала исключение, если значение константы TVF было NULL. В этом случае GPORCA теперь корректно возвращается к планировщику.
Наконец, решена проблема, из-за которой GPORCA мог аварийно завершать работу, когда запрос включал динамическое удаление разделов с динамическим частичным сканированием. А также исправлена ситуация с зависимостями, которая возникала, когда мини-репозиторий запускался по запросу, который обращался к материализованному представлению.
В отношении потока данных решена проблема с программой, управляющей пулом соединений pgbouncer, из-за которой пользователи с правами администратора, входившие в ее базу данных, регистрировались как пользователь pgbouncer, а не как настроенный пользователь admin_user.
Освойте администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
