Článek je sice informačně zajímavý ale vstupní premisa jako taková je nesmyslná. MySQL samozřejmě je open source. Je source open? Je, takže to je open source. Že je ten projekt špatně vedený, komunitní vývoj v podstatě nefunguje a Oracle to zcela nepřekvapivě agresivně monetizuje a jinak zabíjí je sice politováníhodné, ale s tím, jestli jde o open source projekt nebo nejde to nesouvisí.
On predevsim zadnyho "uzivatele" henten opensource ... naprosto nezajima.
Zajimajiho ho naklady a prinosy. Pokud nekomu neco 30+let jede na MySQL, tak naprosto logicky nevidi naprosto zadnej duvod k tomu, aby to migroval na mariu (natoz nekam jinam) a potazmo resil nejakou nekompatabilitu. Proc by to jako mel probuh delat?
A pokud tu nekdo zminuje PostgreSQL, tak by me zajimalo, kolikrat na tom delal upgrade verze ... protoze se vpodstate pokazdy neco podela a je treba neco resit ...
Migrací Postgresu jsem dělal stovky - od dob, kdy se začal používat pg_upgrade, upgrade samotný vždy prošel bez problémů. V posledních letech jsem viděl u zákazníků bezproblémové přechody z 15-16, 16-17, a teď nedávno z 17-18. Neviděl jsem, že by se upgrade podělal.
Viděl jsem, že s novějšími verzemi některé aplikace pro monitoring měly problém - dochází ke změnám systémového katalogu a bez podpory novější verze to samosebou failne. Dnes už spíš výjimečně se narazí na nějaké problémy s kompatibilitou - vzpomínám na přechod na ANSI stringy nebo změna formátu bytea. Téměř vždy se objeví nějaké důsledky práce na optimalizátoru - pár dotazů v aplikaci se chová jinak - pár je rychlejších, pár je pomalejších. Dost problémů je způsobeno tím, že uživatelé po upgrade nepustí ANALYZE. To se dělo hodně kolem 10-12. Měnila se optimalizace CTE, zaváděl se JIT. To se stát může - zvlášť u dotazů, kde jsou špatné odhady. Nicméně rozhodně se to nestává pokaždé - a problémy s optimalizací vám mohou nastat i v provozu nárůstem tabulek (nebo po přidání indexu).
To ale není specifikum Postgresu - to platí pro každou databázi, která negarantuje 100% zpětnou kompatibilitu u optimalizace. U MySQL v 8čkové verzi došlo k razantnímu přepisu optimalizátoru - tam problémů s dotazy muselo být mraky. A co se dívám na release notes MySQL i MariaDB, tak optimalizaci dělají dost změn a dost pochybuju, že by garantovali neměnnost plánů. Jak MySQL tak MariaDB má nyní optimalizaci podobnou Postgresu - u složitějších dotazů dostanete lepší plány - na druhou stranu tam bude vyšší citlivost na statistiky. A ten přepis optimalizace museli udělat, protože ve starších verzích MySQL optimalizace složitějších dotazů nebyla dobrá.
15. 1. 2026, 06:16 editováno autorem komentáře
To se asi nestane. Použití starých binárek je trik, aby se nemusela držet historie v aktuálním kódu. A navíc by to asi ani nešlo v aktuálním designu. Systémové tabulky jsou prakticky zakompilované do kódu - ke každé systémové tabulce existují Cčkové struktury, které samozřejmě musí být kompatibilní s tím, co je na disku. Nemůžete napsat binárku v Postgresu, která by uměla efektivně pracovat se systémovými tabulkami z jiné major verze.
Resp. napsat by to šlo, ale znamenalo by to udržovat hromadu historického kódu. pg_upgrade se může použít pro 15 let (a možná ještě víc) staré verze - s tím, že si jednoduše zavolá starou binárku.
Provozujeme stovky instancí PostgresSQL u klientů a problémy při upgradu obecně nejsou. Rozhodně s upgradem MariaDb je těch problémů mnohem víc. Ne že by snad samotná databáze po upgradu nefungovala či ztratila data, ale změní svoje chování a se stejným nastavením se začně chovat jinak, což má typicky vliv na výkon některých query a někdy i na výsledky. Vyřešit lze někdy úpravou konfigurace, ale častěji je potřeba upravit query v aplikaci. PostgreSQL je v tomhle konziistentní a nepamatuju si, že by upgrade ( i přes několik major verzí ) způsobil podobné chování.
Asi jediná past u PostgreSQL, co si vybavuju, nesouvisí ani tak s upgradem databáze jako toho okolo. Po změně verze glibc je potřeba udělat refresh collation. Na to když se zapomene, tak to umí řádně pozlobit. V dokumentaci je to samozřejmě napsané, ale vývojáři naštěstí ( od verze 15? ) přidali warning po příhlášení do databáze, což je fajn.
Mluvis predpokladam o tomhle:
"
The database was created using collation version 2.40, but the operating system provides version 2.41
Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION
"
To je taky znamka uzasnyho pristupu ... proc si to kua neudelaj ... a to ani (jak je vidno) u systemovy databaze...
Nevím, co myslíte systémovou databází? Postgres žádnou systémovou databázi nemá.
Tohle má historické pozadí - Postgres je databáze navržená primárně pro Unix a Unix má integrovanou podporu collation v knihovně libc - tady jde o primárně o řazení. Nicméně se ukázalo (a to relativně pozdě - ani ne 10 let zpátky), že implementace těchto řadících algoritmů není stabilní. Což samozřejmě vede k riziku curruptnutí indexu. A když už jsem u historického pozadí - je to databáze z US, do které se podpora 8bit kódování dodělávala hodně pozdě, a nikomu v té době nedocvaklo, jaké problémy s glibc mohou nastat - libicu ještě neexistovala - a implementace vlastní podpory collations ve stylu MySQL se zdála šílenost - když byla podpora v libc (v POSIXu).
Nicméně vlastní implementace collation také není absolutní řešení. Jakmile jednou vydáte nějaké collation - už ho nemůžete fixnout. Můj první patch paradoxně nebyl do Postgresu, ale do MySQL - opravovali jsme řazení pro češtinu. Mám pocit, že nikdy nebylo commitnuté - právě, že byl potřeba rebuild indexů.
Ten ALTER můžete dělat až po rebuildu indexů - ne dříve. A rebuild indexů může být dost zdlouhavá záležitost - nic co byste chtěli, aby systém udělal automaticky. Navíc tohle může být také falešný alarm - glibc nemá sémantické verzování collations, takže je na vás abyste se rozhodl - jestli budete reindexovat nebo to ignorovat.
V tom je lepší libicu, která má sémantické verzování pro collation - takže už nedojde k falešným alarmům. Bohužel - realita je taková, že collation nemůže být neměnné - dochází k opravám, mění se normy, ... Jediné 100% immutable colllation bude C, případně C UTF8, tam by tento problém neměl nastat.
"A rebuild indexů může být dost zdlouhavá záležitost - nic co byste chtěli, aby systém udělal automaticky."
Vskutku ... u tech desitek databazi ktere mam kolem sebe se to vubec nespousti zcela automaticky, protoze to vubec neni zaklad udrzby zcela libovolne databaze ...
Loni jsem delal takovou operaci ... inplace upgrade win srv ...a ono to nejakym rizenim osudu proslo ... ale co vic, na tech widlich bylo mssql ... a nasledny inplaceupgrade te databaze, prosel take. Nikde to nehlasilo ani zadne errory, ani zadnw warningy a ano, bezelo to slusnou davku hodin. A vse co si to chtelo prekopat si to proste prekopalo.
"Nevím, co myslíte systémovou databází"
DATABASE postgres
Ono se to da provozovat bez ni? Ok, ja ji smazu a reknu ze mi bylo receno ze je zbytecna, ja tam zadnou takovou nevyrabel.
MSSQL nepoužívám, tak se mohu plést, google ale naznačuje, že rebuild indexů automaticky nedělá.
MSSQL beží na Windows a teoreticky na Linuxu. Postgres běží na Linuxu, Windows, MacOS, AIXu, BSD, ... integrace se systémem je mnohem slabší - a i automatizace. Postgres se nesnaží všechno udělat za uživatele. pg_upgrade je udělaný tak, aby běžel, co nejrychleji - pokud chcete neřešit tento problém, tak použijte pg_dump.
Databáze Postgres není systémová databáze. Můžete ji klidně smazat - Postgresu samotnému to vadit nebude - může to vadit některým aplikacím, které se primárně hlásí do db postgres, protože jsou tak nakonfigurované. Ta databáze je tam jen kvůli tomu, aby se aplikace měly kam hlásit, a neblokovaly db template1.
Vskutku ... u tech desitek databazi ktere mam kolem sebe se to vubec nespousti zcela automaticky, protoze to vubec neni zaklad udrzby zcela libovolne databaze ...
Opravdu vám všude ten rebuild dělá databáze automaticky zcela sama od sebe kdy jí napadne, třeba uprostřed největší špičky? Nebo autoři té aplikace ručně naplánovali, kdy se má rebuild indexů dělat?
bezelo to slusnou davku hodin
Možná někdo dává přednost tomu, že nemá databázi odstavenou několik hodin, ale odstávka je co nejkratší a některé části upgradu se udělají až za provozu databáze (třeba se níženým výkonem).
Tohle je jeden z důvodů proč není ideální dělat naráz upgrade Postgresu a upgrade operačního systému. A pokud lidi nemají trochu znalosti, tak pak jsou překvapení. Nicméně ten problém s glibc je relativně nový, a když se to poprvé objevilo, tak všichni byli hodně špatní - teprve pak se tam přidaly kontroly na které narážíte -- mohou tam být maximálně 5 let - předtím mohlo dojít k tichému poškození indexů :-/ a nikdo nechápal, proč.
Pojem open source je dnes širší, nejde jen o licenci a dostupnost kódu, ale též o komunitní řízení projektu, které zaručuje nejen otevřený kód, ale též otevřený vývoj. V článku to je krásně popsáno a pasuje to na řadu dalších korporátů, které opensource podporu jen markýrují.
https://almaer.com/blog/community-driven-open-source
https://www.cmswire.com/cms/enterprise-cms/nuxeo-vs-alfresco-how-do-you-like-your-oss-001254.php
14. 1. 2026, 17:44 editováno autorem komentáře
Ten článek by mohl používat termín třeba opensource komunitní projekt. Asi na to není zavedený žádný ustálený pojem, ale bylo by ho potřeba - včetně nějaké metriky, která by hodnotila kvalitu vedení projektu. Opensource sám o sobě není ještě zárukou benefitů, které dnes často (ne zcela správně) s pojmem opensource spojujeme.