PostgreSQL: Nás jen tak neodrovnáte (diskuse)

[Hlípa]

Presne tohle jsme diskutovali loni na PGCONu. A v podstate se da akorat ten vyvoj zpomalit a trvalo by asi tak dva roky, nez by se to zase nejak rozjelo. Tech klicovych lidi kolem Postgresu je par. Da se rici ze tak 5 (Tom Lane, Heikki, Simon Riggs, Alvaro, Greg Stark)+ jeden, dva lidi z Japonska. Pak je skupina vyvojaru, kteri delaji specificke veci, jako TSearch (Oleg a Teodor), PgPsql (Pavel), win port (Magnus, Dave), build zalezitosti (Peter Eistentraut). Ale komunita je sirsi a novy lide prichazeji.

Problem je akorat v tom, ze ten kod je tak komplexni, ze uz to malo kdo pobere. Takze trva tak dva roky nez se nekdo dostane na skutecne dobrou uroven, aby mohl psat velke featury.

[faha]

Mno tak to smekam, vazne na tom dela takhle malo "core" lidi? Tak to jsem netusil a musim tedy smeknout a podekovat. I bych rad pridal ruku k dilu, ale jak je zde psano je to tak komplexni, ze je to nejspise nad moje moznosti to pochopit. Presto velmi dekuji.

[Hlípa]

Tak je spoustu malych veci, kterych se da udelat. Napriklad utilitky kolem. Nebo vylepseni psql ci JDBC driver. Je toho spousta a i maly patch je dobry patch. Studenti si pak mohou vybrat nejakou zajimavou bakalarku ci diplomku. Vyhodou Postgresu je, ze ackoliv kod je komplexni je velmi dobre zdokumentovan.

[R]

Napriklad by to chcelo zjednodusit pracu administratorom. Kym upgrade mysql je trivialna zalezitost, upgrade postgresql nie. Prave s tym bojujem.

[tomm]

Upgrade minoritni nebo majoritni verze PSQL?

[R]

8.1 na 8.4 v Gentoo. Uz som to rozchodil. Ciastocny podiel viny na tom bordeli ma aj Gentoo - zmenili sa prava adresara so socketom. Niektore "inteligentne" programy (phppgadmin) nevedia vypisat, v com je problem.

[ute]

PostgreSQL užívám už od verze 7.0 a VŽDY byl upgrade snadná záležitost: - dump celé databáze - instalace nové verze - obnovené dumpu

Pokud máte problém, rád pomohu

[Amarok]

Ted se zeptam asi trochu blbe: proc dump databaze? Upgrade smaze nebo ponici databazi? To bych docela rad vedel, nez nejakym upgradem prijdu o data.

[Heron]

DB (a nejen ta) může měnit formát dat na disku mezi svými významnými verzemi a nikde není zaručeno, že nová verze přečte nějaká stará data. Jediný správný postup je tak vytvořit dump (který je dostatečně univerzální a popisný), a do nové verze jej loadnout.

[tomm]

Proto jsem se ptal na ten minoritni vs. majoritni. U minoritni verze jsou binarni databazove soubory kompatibilni a je mozne je "na hulvata" zkopirovat. U zmeny majoritni verze je samozrejme nutny dump. Ale neznam DB, kde by to nebylo. Kdysi jsem u Oracle cetl nejake silene postupy, jak to upgradnout, ale podle me by to delal jenom silenec.

[nail]

ake salene oracle? backupnes DB, nainstalujes novy SW; a spustis upgrade to je cele

[tomm]

Je to z doby nejake verze 7->8. Tehda mi to zhavarovalo. Verim, ze pri aktualnich verzich 9->10->11 to funguje dobre, ale zkouset to nebudu. Taky proc, kdyz mi mezitim moralne zastaralo zelezo a na novy stroj jde novejsi stabilni verze

Skutecny prodo jsem zazil s paralelnim behem 2 verzi Oraclu, doufal jsem, ze to pres oddelene produktove adresare pujde dobre, ale tenkrat me hrozne moc potrapili listenery.

Posledni problem, co jsem resil byl, ze kdyz jsem mel nainstaloval cisty Oracle ve virtualu a ten pak rozkopiroval, prejmenoval stroje, zmenil IP a jmena, tak opet nenastartovali listenery, i kdyz bylo vsechno pekne predelane a prejmenovane. DB jako takova bezela, jako sysdba jsem se lokalne prihlasil (cili tnsnames byl OK), ale listener nic, proste zahada. Skoda, usetrilo by mi to spoustu casu.

[nail]

no ja som zacnal na 9i, 8i dole nepoznam vobec :)

listener je otazka jedneho configu, inde problem nemoze byt, jedine env ze by ukazoval na nejaku "somarinu"

/ as sysdba nepouziva tnsnames

[tomm]

Pravda, to me trklo az potom, ze / as sysdba obchazi asi vsechno

Ja jsem se to snazil par hodin preprat a proste to se mnou nemluvilo. I jsem vse smazal, vytvoril znova, prosel i nastaveni site a porad jsem dostaval notoricky "Network problem" pri startu listeneru. Proste zahada, vim ze mi to pri prenosu stroje ze site d osite normalne fungovalo. Jen se muselo dat bacha na jmena, nekdy pak nechce chodit dbca

A stejne mam radsi PSQL, je to takove nejake jednodussi, jen mu chybi nektere vlastnosti, tak doufam, ze chlapci zamakaji

[Shadow]

jen mu chybi nektere vlastnosti, tak doufam, ze chlapci zamakaji

No, můžeš jim pomoct a přiložit ruku k dílu.

[tomm]

No, to je bohuzel v rovine ruzove budoucnosti Ja tak maximalne hodne testovat a prosazovat u zakosu, aby se o PSQL vice vedelo.

[Shadow]

Ja tak maximalne hodne testovat a prosazovat u zakosu, aby se o PSQL vice vedelo.

Však i to se počítá.

[tomm]

Pomalu je zasimilujeme

[okbob]

Mezi velkými verzemi může dojít, a zpravidla i dochází, ke změně systémových tabulek. Navíc dochází - a to už spíš zřídka, ke změně formátu uložení některých datových typů. Všechny tyto změny jsou spojené s přechodem tzv. velkých verzí např. mezi 8.3 a 8.4. V rámci malých verzí - např. 8.3.1 a 8.3.2 je garantována kompatibilita. Migrace dat mezi velkými verzemi je možná několika způsoby - prostřednictvím pg_dumpu, slony. Teď už se několik let pracuje na pg_migratoru, což je další způsob, který by se v budoucnu měl používat pro extrémě velké databáze - kdy je dump omezující.

Upgradem o data příjít nemůžete - pg si kontroluje, zda formát odpovídá verzi a v případě, že ne, tak se pg odmítne nastartovat - tudíž Vaše data zůstanou nedotčená.

[xkucf03]

BTW: co znamená v 8.5

Hot Standby: allow read only connections during recovery

Je to použitelné i při normálním provozu (nejen při „recovery“) jako kopie dotazy? Tzn. zápisy budu dělat na „mastera“ a pak budu mít několik „slavů“ na které rozložím čtecí operace?

[okbob]

Ano - tak by to mělo fungovat.

[okbob]

http://www.depesz.com/index.php/2010/01/08/waiting-for-8-5-hot-standby/

[R]

Ten pg_migrator vyzera by presne to, co by som chcel. Nainstalujem novu verziu a spustim konverziu. Tym padom nehrozi, ze nieco pokazim pri vytvarani a nastaveni noveho clusteru.

[trekker.dk]

Upgrade smaze nebo ponici databazi?

Pokud v Debianu uděláš apt-get remove --purge (tj. odinstalovat a smazat konfiguraci), DB se smažou.

[JoHnY2]

Velmi logicka vec, co. Jeden by cekal ze se ho to pri purge na tak dulezitou vec jako data aspon zepta, kdyz uz je to maze.

[trekker.dk]

Docela jo, štěstí, že ta DB byla testovací a měl jsem jakous-takous zálohu.

[happy barney]

odkedy existuje slony, upgrade na vyššiu verziu je triviálna zaležitosť

[okbob]

Ve skutečnosti na PostgreSQL dělá "mnohem" víc lidí - pravidelně tak kolem třiceti - jednorázově určitě víc než sto. Ta užší skupina je podstatná proto, že udržují a rozšiřují, pro PostgreSQL, kritické části - jako je optimalizace, storage, správa cache, správa transakcí. To je kód od kterého si ostatní docela rádi udržují odstup. Zbytek - cca 70% kódu je překvapivě jednoduchý - a nezanedbatelná část patchů je od programátorů, kteří s postgresem s postgresql pracují poprvé.

Pokud byste chtěl pomoci - tak nemusíte začínat jako programátor. Můžete se zapojit do procesu review patchů - což znamená otestovat patch, pochopit co dělá, zhodnotit zda-li je kód dostatečně zdokumentovaný, otestovat zda-li to dělá, to co by to mělo dělat. Tím se člověk může hodně naučit - a i hodně pomoci, protože core programátoři se mohou soustředit na finální úpravy.

http://archives.postgresql.org/pgsql-rrreviewers/

[okbob]

Ještě bych dodal, že vývojáři, které Zdeněk jmenoval nepracují pro Pg na jeden úvazek, ale spíš na dva až tři. Jejich práce je ohromně vidět, ale stojí to tuny času.