Начинаем серию статей о сотрудниках Postgres Professional, которые получили медали за вклад в сообщество PostgreSQL. Как начать контрибьютить и что из этого может получиться — в интервью с сore developer Алёной Рыбакиной.

 

— Алёна, за что ты получила медаль? 

— За многочисленные ревью разных патчей: находила их в коммитфестах, смотрела, как они работают, оставляла фидбэк. Где-то нужно было просто добавить тесты, а где-то находились поломки и непредусмотренные сценарии. Позже я начала работать над собственным большим патчем — OR-ANY Transformation. Расскажу о нём подробнее.

Суть проблемы, которую решал мой патч, заключалась в неэффективной работе оптимизатора с большим количеством OR-условий для одной и той же колонки. До моего патча оптимизатор PostgreSQL предпочитал выполнять Bitmap Index Scan для каждого OR-выражения в колонке по отдельности. Приходилось многократно сканировать одни и те же страницы индекса, вместо того чтобы пройтись по ним один раз. 

Мой патч трансформировал такую конструкцию в более эффективный Index Scan (или Index Only Scan), который проходился по страницам индекса всего раз и уже во время этого сканирования фильтровал нужные значения. Работа над этим патчем заняла около года, но в конце концов его приняли и закоммитили в 17-ю версию PostgreSQL.

— Алёна, расскажи про патч, связанный с оптимизатором: ты его придумала во время ревью или столкнулась с реальной проблемой и патч её решил? 

— Всё было немного иначе. Пришёл клиент, у которого фреймворк не умел обрабатывать операторы IN, и запросы со множественными условиями для одного поля приходилось строить через цепочки OR. Было очевидно, что здесь помогут IN-операторы. Но проблема была в масштабе: фреймворк генерировал 50 тысяч OR-выражений для одной колонки. При генерации плана выполнения такой запрос потреблял около 1,5 ГБ памяти и просто падал от memory kill.

Поначалу задача казалась немного надуманной: очевидно, что проблема была во фреймворке, а не в оптимизаторе. В итоге клиент решил свою проблему, сменив фреймворк, и даже не стал дожидаться нашего патча. Но нам проблема показалась интересной, и мы продолжили заниматься ею. Уже в процессе работы над патчем на моё письмо в рассылке ответил известный коммиттер Питер Гейган (Peter Geoghegan) и скинул ссылку на свой проект, который был тесно связан с моим. В итоге мы доделали патч, и сообщество его приняло. Так что изначально проблема, можно сказать, пришла «из ниоткуда».

— Почему ты вообще решила заниматься ревью патчей?

— Никакого специального проекта не было. Я понимала, что мне нужно делать ревью, чтобы повысить свои скилы. Подтолкнул меня к этому мой экс-коллега Андрей Лепихов, который активно контрибьютит в PostgreSQL. Он считает, что лучший способ прокачать навыки — это смотреть, как другие разработчики пишут и оформляют патчи.

Чем отличился Андрей Лепихов

Андрей, как и Алёна, получил медаль за вклад в сообщество: он обнаружил ошибку в коде, когда вместе с коллегой Николаем Шапловым проверял гипотезы по фаззингу автономных транзакций. Судя по всему, ошибка была давнишней, но устранять её почему-то не спешили. Благодаря этой находке Том Лейн закрыл одну из уязвимостей PostgreSQL. 

Сначала было очень тяжело: непонятно, о чём писать, что искать, что делать. Но потом всё завертелось само собой. Сейчас я стараюсь делать ревью как можно чаще, хотя из-за основной работы не всегда успеваю. Это отличный способ и прокачать навыки, и заявить о себе в комьюнити.

— Что по-твоему «нормальный патч», который пройдёт ревью максимально быстро?

— Это сильно зависит от сути патча. Можно выделить три основных сценария.

1. Багфикс. Как правило, самый быстрый путь. Здесь главное:

  • Проверить стилистику кода: комментарии должны быть правильно поставлены и объяснять, почему добавили, изменили или удалили эту строчку. Комментарий к коммиту должен понятно описывать проблему и объяснять, как патч её решает.

  • Добавить регрессионные тесты, который показывают, что без вашего патча код падает, а с патчем нет. Это поможет другим разработчикам не наступить на те же грабли. Иногда добавить тест-кейс невозможно (например, если баг связан с аномальным потреблением памяти). Ревьюеры могут это понять, но если тест возможен, он должен быть.

  • Проверить, чтобы патч ничего не ломал.

2. Новая фича. Это самый сложный и долгий путь, как было с моим OR-ANY Transformation.

  • Доказать, что ваша фича ничего не ломает. Нужно очень много тестов. Вы должны показать, что ваша фича корректно работает со сложными планами, множеством JOIN, пользовательскими операторами и не ломает существующие оптимизации. Результаты запросов с вашим патчем и без него должны быть идентичны.

  • Будьте готовы к долгому ревью. Ревьюеры будут приходить и целенаправленно искать, как сломать ваш патч и что вы упустили. Это хорошо! Чем больше людей посмотрит ваш код, тем меньше шансов, что после коммита придут разгневанные пользователи. Даже у нас после коммита нашёлся неприятный баг, который мы всё-таки пропустили.

3. Документация. Это самый простой вариант. Вы видите проблему в документации и предлагаете исправление. Здесь нет кода, поэтому ревью обычно проходит быстро. Могут придраться к формулировкам, но это мелочи.

— Алёна, что посоветуешь начинающим разработчикам, которые тоже хотят ревьюить?

— Мои советы основаны исключительно на личном опыте, и они таковы:

  • Погрузитесь в предметную область. Я сфокусировалась на своей сфере — оптимизаторе запросов — и искала любые доступные материалы, чтобы глубоко разобраться в теме.

  • Просто начните. Я понимала, что не готова на 100%, но всё равно взяла первый интересный мне патч и стала в нём копаться: разбираться в проблеме и предложенном решении.

  • Начните с простого. Самый лёгкий старт — это патчи для документации. Они помогают понять, как всё устроено внутри, а их ревью — это уже ценный вклад.

  • Не бойтесь маленьких шагов. Даже если ваш фидбэк — это просто письмо в рассылку с предложением поправить комментарий в коде, это уже нормальный вклад.

  • Будьте терпеливы. Иногда готовый патч может долго ждать своего коммиттера. Они могут быть заняты более срочными проблемами (например, критическим багом у клиента). Это нормальная часть процесса.

Главное — взять патч, спокойно сесть, разобраться и отправить письмо со своими мыслями. 

Могу продолжить знаменитую мудрость китайского философа Лао-цзы: «Путь в тысячу ли начинается с первого шага, а путь в коммиттеры PostgreSQL — с первого ревью».