Názory k článku
PostgreSQL 18 bude výrazně rychlejší s IO_uring

Jak je to vlastně s bezpečností io_uring? Nebylo s tím spojeno hodně bezpečnostních chyb?

bezpečnost s io_uring je hlavně problém na serverech, kde se může spouštět kód více uživatelů najednou, v případě databáze můžeš pracovat s tím, že tam nic jiného neběží.

Dá se to řešit tím, že budeš třeba přes seccomp-bpf nebo selinux filtrovat, který proces může io_uring používat, tím to omezíš jen na třeba databázi, která z toho může těžit a u ostatních to zamezíš. Problém to je ale v kontejnerech.

Nic ale nebrání tu podporu mít dopředu.

Pozor - ten test je extrémně syntetický. Praxe bude jiná - v OLTP jsou ve většině připadů data v cache, a v OLAPu zas bude Postgres brzdit fakt, že nemá vektorový executor a nemá sloupcový engine. Motivací pro implementaci AIO je víc - aktuálně možná je důležitější možnost jednodušeji (a standardizovanou cestou) obejít filesystémovou cache v těch případech, kdy je jasné, že cache je zbytečná - checkpoint, vacuum, .. V každém případě se jedná o zásadní refaktoring, který do budoucna umožňuje jednodušeji používat různá API pro IO - tipoval bych, že 99% uživatelů nepozná rozdíl (můžu se plést - bude trvat dva tři roky než se s tím získají reálné zkušenosti).

Za mna (amater, nadsenec, v tejto oblasti) verim, ze to prinesie kusok rozdiel pri non-blocking spracovani... aj ked stale sa nechytaju vlakien a nesmeruju k non-blocking spracovaniu, tak to moze byt teoreticky prva zmena v tomto smere... mat moznost neriesit (nekonfigurovat) pocet spojeni a mat funkcnu sluzbu aj pri menej rozumne napisanych aplikaciach by bolo pekne...

PS: stale som sa nepozeral, ci r2dbc drajver je naozaj non-blocking, alebo len nejako zakryva spracovanie za asynchronicitu... takze .ozno samotna DB nieje poslednym chybajucim clankom. (A ani neviem, ci mnesia v erlangu je tiez non-blocking, alebo ci existuje nejaky ini, produkcny, stack s touto vlastnostou)