Сүүлийн 10 жилд анх удаа: Postgres 19 хойшиллоо — AI-ийн илрүүлсэн алдааны "цунами" нээлттэй эхийн ахмадуудыг живүүлж байна

Сүүлийн арван жилийн турш нээлттэй эхийн ертөнцөд нэгэн бичигдээгүй хууль мэт баттай мөрдөгдсөн цаглабар байсан нь PostgreSQL өгөгдлийн сангийн шинэ хувилбар жил бүрийн 9-р сарын дундаас 10-р сарын дунд үеийн хооронд цаг шиг нарийн гардаг уламжлал байв.

Гэвч 2026 онд энэ уламжлал тасарлаа. Postgres 19 хуваарийн дагуу гарсангүй, хамгийн наад зах нь 11-р сар, магадгүй түүнээс ч цааш хойшлогдохоор боллоо. Үүгээр ч зогсохгүй олон жил хүлээгдсэн SQL Property Graph Queries (SQL/PGQ), UPDATE/DELETE FOR PORTION OF, болон ALTER TABLE ... MERGE/SPLIT PARTITION зэрэг гурван том архитектурын өөрчлөлтийг бета шатны сүүлийн өдрүүдэд codebase-аас яаралтай буцаан татсан (revert) байна.

Дэлхийн хамгийн тогтвортой өгөгдлийн сангийн нэгэнд гэнэт юу тохиолдов? PostgreSQL-ийн гол committer, ахмад инженер Роберт Хаас (Robert Haas) үүний учир шалтгааныг өөрийн нийтлэлдээ нэг л өгүүлбэрээр хариулжээ: "Товчхондоо бол LLM (хиймэл оюун) нөлөөллөө."

---

40 жилийн настай кодоос алдаа "ухах" тэсрэлт

PostgreSQL-ийн git түүх нь тэртээх CVS системийн үеэс эхлээд 30 гаруй жил, харин анхны код нь бичигдсэнээс хойш бараг 40 жилийг элээжээ. Ийм том, хуучин бөгөөд нарийн төвөгтэй системд алдаа байх нь жам ёсны үзэгдэл.

Харин энэ жил нэг зүйл сууриараа өөрчлөгдсөн нь: кодоос алдаа илрүүлэх үйл явц хиймэл оюуны тусламжтайгаар урьд өмнө төсөөлж байгаагүй хурдаар хялбар болжээ.

Роберт Хаасын дэлгэсэн статистик хачирхалтай тоон баримтыг өгүүлж байна:

• 2025 оны feature freeze-ээс хойш stable салбарт (REL_18_STABLE) ердөө 724 commit орж байсан бол, 2026 оны яг ижил хугацаанд REL_19_STABLE салбарт 1169 commit хийгдсэн нь даруй 60%-иар өссөн үзүүлэлт юм.
• Бүр ноцтой нь, өмнөх хувилбарууд руу эргүүлэн patch хийх (back-patching) тохиолдол жилийн дотор 74%-иар огцом өсжээ (248-аас 433 болж өссөн).

Энэ нь core хөгжүүлэгчид гэнэт муу код бичээд эхэлсэн гэсэн үг биш. Харин дэлхий даяар олон мянган судлаач, хөгжүүлэгчид LLM моделиудыг ашиглан Postgres-ийн эртний C кодоос edge case, memory leak, concurrency race condition зэрэг далд алдаануудыг "ухаж гаргаж" ирээд GitHub болон mailing list-ээр бороо мэт асгаж эхэлсэнтэй шууд холбоотой юм.

---

Шинжилгээ хурдан ч, баталгаажуулалт (Verification) хүний нуруун дээр хэвээр

AI алдааг маш хурдан илрүүлж, засах зориулалттай patch хүртэл бэлтгэж чадаж байгаа нь үнэн. Гэвч асуудал үүнд л оршиж байна:

1. LLM-ийн засварууд PostgreSQL-ийн стандартад нийцдэггүй: Хиймэл оюуны санал болгож буй patch нь харахад ажиллаж байгаа мэт боловч architectural consistency, performance, lock contention зэрэг нарийн асуудлуудыг дутуу тооцсон байдаг.
2. Хүний тархи клондлогдоогүй: PostgreSQL төслийн committers-ийн тоо 2025 оноос 2026 оны хооронд нэмэгдээгүй, тэдний бүтээмж гэнэт 2 дахин өсөөгүй.
3. Хугацааны булаалцалдаан: Төслийн үндсэн инженерүүдийн шинэ боломжууд (features)-ыг хянаж, сайжруулахад зориулах ёстой байсан бүх цаг зав нь дэлхий даяас ирсэн олон зуун аюулгүй байдлын цоорхой болон backport засваруудыг нягтлах руу бүрэн зарцуулагдаж таарсан байна.

Үүний уршгаар хугацаа тулж, хангалттай шалгаж амжаагүй гурван том шинэ боломжоо эрсдэлээс сэргийлэн хасахаас өөр аргагүй болж, Postgres 19-ийн албан ёсны нээлт хойшлогдлоо.

---

Нээлттэй эхийн "Шинэ Тэнцвэргүй Байдал" (The Asymmetry Problem)

Энэхүү үйл явдал зөвхөн PostgreSQL-ийн тухай бус, нийт програм хангамжийн салбарын ирээдүйн аюулыг тодотгож өглөө.

• Алдаа олох, код үйлдвэрлэх зардал бараг 0 рүү дөхөж байна.
• Харин кодонд хариуцлага хүлээх, архитектур батлах, эцсийн бүтээгдэхүүнийг хянах хүний анхаарал хамгийн ховор, үнэтэй нөөц хэвээр үлдэв.

Хэрэв цөөн тооны сайн дурын ахмад инженерүүдээр тогтдог Linux цөм, SQLite, PostgreSQL зэрэг суурь дэд бүтцийн системүүд рүү сая сая хиймэл оюуны гаргасан bug report, PR-ууд чиглэвэл maintainer-үүд ажлын ачааллаас болж бүрэн сөхрөх аюул ойрхон байна.

---

Хөгжүүлэгч бидэнд өгөх сургамж

Танай баг ч гэсэн дотооддоо Cursor, Claude, Copilot ашиглан техникийн өр (technical debt) хайж, кодоо дахин засварлаж байгаа бол дараах зүйлийг анхаарах цаг болжээ:

• Review хийх хүчин чадлаа бодитой тооц: Код бичих, алдаа олох нь ажлын дөнгөж 30 хувь. Үлдсэн 70 хувь нь хүний чанартай review, regression testing болон integration байдаг.
• Bug-д бүрэн найдах хэрэггүй: AI-ийн олсон жижиг corner-case алдаануудад хэт төвлөрч, бизнесийн үндсэн логик болон шинэ боломж бүтээх гол замаасаа хазайхаас сэргийлэх нь чухал.
• Автоматжуулсан Eval болон Harness нэвтрүүлэх: Зөвхөн кодоор бөмбөгдөх биш, тухайн засварыг өөрөө тестлэж баталгаажуулдаг найдвартай CI/CD pipeline байхгүй бол хүний хянагчид гацаанд ордог жамтай.

Postgres 19-ийн хойшлолт нь AI-ийн эрин үед "Код бичихээс илүүтэй чанарыг шүүн тунгаах нь программ хангамжийн хамгийн хэцүү даваа болж хувирсныг" бүх салбарт тод сануулсан дохио боллоо.

---

Эх сурвалж: Robert Haas (rhaas.blogspot.com / Databricks), Hacker News хэлэлцүүлэг.