Пожалуй лучшее объяснение, почему я оставляю вещи на стуле😅

Первый месяц на позиции TeamLead выглядит именно так😅

Говорят, чтобы стать профессионалом в любой сфере, нужно 10 000 часов практики.

Если тратить на развитие по 40 часов в неделю — это 250 недель, то есть примерно 5 лет непрерывной работы (именно поэтому в вакансиях для уровня senior требуют опыт работы от 5 лет). Надо 5 лет, чтобы выйти на уровень эксперта…

Но давайте честно: а можно ли быстрее?

Ведь далеко не все рабочие задачи реально качают скилл. Можно годами решать однотипные тикеты и оставаться на том же уровне.

По-настоящему мы растём, когда сами ищем новое, пробуем, экспериментируем, ошибаемся и исправляемся. Не ждём «особой задачи», которая вдруг нас вытащит на новый уровень, а сами становимся источником своего роста.

Потому что правда проста: ни ваш руководитель, ни компания, ни коллеги, ни даже ментор не заинтересованы в вашем развитии так, как вы сами.
За ваши навыки отвечаете только ВЫ.

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

А когда и что нового вы в последний раз изучили в своей сфере?

У кого хоть раз такое было?)

🚀 Меньше двух недель до нашего backend-митапа

Приходи, чтобы погрузиться в многопоточность, микросервисы, промпт-инжиниринг и System Design с разработчиками из BigTech. Разбираем то, что нужно для работы и успешных собеседеоний.

• Когда: 20 сентября
• Где: Москва, Пространство «Весна»

🎟️ Еще остались билеты, поспеши!

Приобрести билет можно по ссылке: https://clck.ru/3Nd8ea

Отличная дискуссия получилась — и да, большинство гуру Postgres ответило верно! Давайте спокойно разберёмся, почему.

«Совсем плохой» способ — просто сделать колонку NOT NULL:

ALTER TABLE some_big_table
  ALTER COLUMN foo_field SET NOT NULL;

Почему так делать очень плохо на большой таблице?

Чтобы убедиться, что в столбце нет NULL, Postgres сканирует всю таблицу. Такие изменения вокруг ADD CONSTRAINT/SET NOT NULL обычно требуют ACCESS EXCLUSIVE — самый сильный DDL-лок, конфликтующий со всеми операциями, включая чтения. Это легко превращается в stop the world на таблице, если операция длится долго.

Правильный подход: через NOT VALID → VALIDATE

Идея — разделить «включить проверку для новых записей» и «проверить историю» на два шага.

1. Добавляем ограничение без проверки истории (не блокирует обновления надолго):

ALTER TABLE some_big_table
  ADD CONSTRAINT some_big_table_foo_field_not_null
  CHECK (foo_field IS NOT NULL) NOT VALID;

С флагом NOT VALID добавление не сканирует таблицу и может быстро зафиксироваться. Новые/изменённые строки уже обязаны удовлетворять условию.

2. Отдельно валидируем историю:

ALTER TABLE some_big_table
  VALIDATE CONSTRAINT some_big_table_foo_field_not_null;

VALIDATE CONSTRAINT сканирует только существующие строки и берёт уже SHARE UPDATE EXCLUSIVE (гораздо мягче), так что записи не блокируются так сурово, как при прямом SET NOT NULL.

Что именно могло заблокировать таблицу в нашем кейсе?

Наша SQL миграция выглядит так (все в одной транзакции):

BEGIN;

ALTER TABLE ... ADD CONSTRAINT ... CHECK (...) NOT VALID;
ALTER TABLE ... VALIDATE CONSTRAINT ...;

COMMIT;

В примере я специально указал, что оба действия выполнятся в рамках одной транзакции (многие это заметили).

Однако, когда мы используем сторонние решения для миграций (напрмер goose), мы получаем неявное повдение — миграции в одном файле будут также исполняться в рамках одной транзакции (если не укажем обратное).

В таком случае:
- Мы берем блокировку ACCESS EXCLUSIVE для добавления CONSTRAINT
- Далее эта блокировка будет удерживаться до конца работы транзакции
- Валидация нагрузки происходит долго, что приводит к тому, что транзакция превращается в долгоживующую => таблица заблокирована надолго.

Практический вывод: Делайте ADD CONSTRAINT ... NOT VALID и фиксируйте сразу (быстрый COMMIT). А VALIDATE CONSTRAINT запускайте отдельной миграции и, желательно, в спокойный период.

А чтобы не переживать насчет ваших миграций, вы можете настроить линтер: squawkhq

Cloudflare нашли редчайший баг — прямо в компиляторе Go для ARM64

Да, это не опечатка: не рантайм, не гасе condition в их коде, а чистый косяк в сгенерированном машинном коде Go. И баг был настолько редким, что проявиться он мог только в инфраструктуре масштаба Cloudflare при 84 миллионах НТТР-запросов в секунду.

Не завидую парням, сам пол недели фикшу баги в драйвере на go…

Признавайтесь, у кого так было?)