Разбираемся в дефолтных и откладываемых (деферрабельных) констрейнах в PostgreSQL

В постгре по умолчанию все констрейны проверяются немедленно, сразу после каждой операции(NOT DEFERRABLE INITIALLY IMMEDIATE). Это означает, что уникальные ограничения и внешние ключи всегда валидируются мгновенно, как только происходит изменение данных. Такой подход гарантирует целостность данных, но иногда это создает проблемы. Например, если вы пытаетесь изменить значения в столбце с уникальным индексом, сдвинув их все на единицу, то получите ошибку:

UPDATE numbers SET number = number + 1; \-\- Ошибка: Duplicate key value violates unique constraint

Почему так происходит? Дело в том, что проверка ограничений выполняется для каждой строки в транзакции, и если хотя бы одна из них нарушает уникальность, операция завершается ошибкой. Это неудобно, особенно если вы хотите массово изменить данные в рамках одной транзакции. Но постгрес так же позволяет создавать деферрабельные (отложенные) констрейны, которые проверяются не сразу, а только в момент завершения транзакции при выполнении команды COMMIT.

Отложенные ограничения можно настроить двумя способами. Первый — DEFERRABLE INITIALLY IMMEDIATE — позволяет отложить проверку ограничений вручную, изменив поведение внутри транзакции с помощью команды SET CONSTRAINTS <constraint_name> DEFERRED. Второй вариант — DEFERRABLE INITIALLY DEFERRED — изначально предполагает, что проверка всегда будет происходить в конце транзакции, что особенно полезно в случаях, когда временное нарушение ограничений не критично и будет исправлено до завершения транзакции.

На первый взгляд кажется логичным сделать все ограничения отложенными, ведь это позволяет избежать ошибок при массовых обновлениях и сложных операциях. Однако на практике это может привести к проблемам. Во-первых, использование отложенных ограничений снижает производительность. Планировщик запросов в PostgreSQL полагается на уникальность данных для оптимизации выполнения запросов. Если уникальность не гарантируется на каждом шаге транзакции, то некоторые оптимизации становятся невозможными, и выполнение запросов замедляется.

Также стоит учитывать, что отложенные проверки нельзя использовать для ограничений типа NOT NULL и CHECK. Эти типы ограничений всегда проверяются немедленно, что ограничивает применение деферрабельных настроек.

больше примеров использование деферрабельных констрейнов можно посмотреть тут:
https://emmer.dev/blog/deferrable-constraints-in-postgresql/

https://gekk.info/articles/traceroute.htm

tldr: Traceroute - это хак, а не настоящий сетевой протокол. Он работает случайно и ненадёжно. Маршрутизаторы не обязаны на него отвечать, и часто не отвечают. В современных сетях (особенно с MPLS) он показывает неверную информацию. Отсутствие ответа или высокая задержка в traceroute ничего не значат.

https://www.openwall.com/lists/oss-security/2024/03/29/4

tldr update any rolling release machine, which could caught xz version 5.6.0-1 or 5.6.1-1 (latest - xz-5.6.1-2).

Куча успешных хакерских атак на российский хостинг, если кто-то не заметил. За последнюю неделю пострадали:
— CloudMTS
— 1Gb.ru
— 1cloud
— в свободном доступе куча дампов SQL-баз клиентов Reg.ru

Кроме того — очень много успешных атак на проекты, основанные на 1С-Битрикс.

И что-то подсказывает, что это не конец. Советую всем российским хостингам уделить больше внимания инфобезу, а клиентам — сделать бэкапы и сохранить их у себя "на жоском". Ну, или изыскать возможность переезда на иностранные хостинги.

Gil is no more

https://github.com/python/cpython/pull/116338

GitHub

gh-116167: Allow disabling the GIL with `PYTHON_GIL=0` or `-X gil=0` by swtaarrs · Pull Request #116338 · python/cpython

In free-threaded builds, running with PYTHON\_GIL=0 or -X gil=0 will now disable the GIL. #116322 and #116329 track follow-up work to re-enable the GIL when loading an incompatible extension, and to...