Zdravim, PostgreSQL se zabyvam uz od verze 5.x - to se jeste jmenovalo trochu jinak a nemohu se zbavit dojmu, ze verze 8.0. je, jak to rici kulantne, kvalitativne vyrazne podprumerna oproti ostatnim prelomovym verzim... (7.0 i 6.0).
O vikendu jsem mel moznost vyzkouset a dukladne proklepnout Win32 port (Na WinXP Prof SP1 + updates)... - teda to byl porod. Nevim, ktereho kretena napadlo, ze PGDATA bude v \Program files\Postgresql 8.0\data... bez moznosti si vybrat jinou lokaci. Dalsi zasadni problem je, ze initdb se odmitne zinicializovat na svazku, ktery nema NTFS... takze pokud mate Program files na FAT32 z duvodu rychlosti a NTFS svazek jinde, musite si pomoci rucne - polozka Browse je v instalatoru Disabnuta... (o tom vsem se ale dozvite, az to pri instalaci sleti na drzku)
Dalsi vec je striktni odmitnuti behu pod uzivatelem, ktery ma jakekoli administratorska prava... - na velkem serveru bych to mozna pochopil, na domaci stanici nikoli... ono nejen ze mu vadi Domain admin (budiz), on mu dokonce vadi i Local Admin (kdo doma se zbavuje moznosti instalovat programy a tedy se rucne vykopava z Lokal adminu, kde je defaultne?)
Chapu, ze v Linuxu na to jdeme pres balickovaci system (co jineho je MS Installer?!), takze pozadavky jsou +- stejne, stejne by mohly a mely byt i moznosti.
Jak uz bylo zmineno, pro verzi 8.0 se jiz vice jak 5 let slibovaly replikace. Kazda trosku slusnejsi databaze jiz replikace ma buil-in a na par kliknuti/prikazu je rozchodi (vcetne opovrhovane MySQL, kde diky zretezeni A->B->C->A muze to fungovat i multi-master)... PostgreSQL NIC a to tak, ze vubec NIC... - mame pytel polomrtvych projektu master-slave ci master-multislave (psany od Javy pres perl, TCL apod.), master-master neni v podstate nic. Slony, ktere existuje pouze ve verzi I je master-multislave. Vzhledem k tomu, ze zrovna touto otazkou jsem se jako druhou poradi zabyval cely vikend a prolezl jsem vsechno mozne, vim moc dobre, ze existuje moznost na urovni SPI, triggeru ci jen datovych tabulek. Jako pouzitelne se jevi projekty erServer (Java), Slony, pripadne PgReplikator Japoncu, ktery je primarne urcen pro jine ucely, ale ve sve podstate jako jedinny by teoreticky mohl (prakticky to nikdo nepotvrdil ani v jedine spravne konferenci ohledne replikaci a PgSQL (ktera ma trafic cca 20 mailu mesicne)) fungovat style multi-master. Pak tu mame mrtve (i oficialne) projekty Postgres-R (skoncil u verze 7.2 - ackoli loni v lete mel kdosi snahu to posunout dal, vysledek jsem ani v CVS nenasel), DB(cosi), PPreplication (skoncili u verze 6, teoreticky budou fungovat i s verzi 7.X).
Plne chapu, ze replikace jsou high enterprise oblast, stejne se mi zdalo ujete za tu omezenou funcionalitu erServeru (kuk do historie) davat deset tycek dolaru rocne, bohuzel dneska je uz maji vsichni okolo - aspon master-multislave, zatimco vyvojari misto technicke debaty nad rezolutnimi algoritmy pri kolizich a replikacemi (ano, je co debatovat a rozhodovat jak se bude chovat, protoze pry asyncu to proste jinak nejde a nepujde ani dle teorii), ktere chce vice uzivatelu nez nativni (tim je mysleno to, ze to nepotrebuje viditelne Cygwin a umi to bezet jako service? - ptam se proto, ze Cygwin je vevnitr furt, jen to neni videt, aspon kompilator (= i knihovny) a jako service to snad umime udelat i bez nativniho portu) Win32 port... - nasel jsem nekde i nejake statistiky co chybi vice, kde to sice bylo skoro vyrovnane, ale o par procent take vedly replikace....
Nemohu ci pomoci, drivejsi main release znamenaly opravdu velky posun kupredu, tato 8.0 by mela byt spise 7.5.0, protoze s vyjimkou PITRu (ktery by teoreticky mohl jit vyuzit jako podpora pro ty slibovane replikace - na bazi binarniho transakcniho LOGu funguji replikace u mnoha jinych databazi a to i asynchronne) v podstate ty zmeny nejsou zdaleka takove, jako byly ty jine major verze... uprimne, jsem docela zklaman a verim ze verze 8.1. dotahne nejake nedostatky a treba, jak bylo v konferenci spravne podotknuto se ve verzi 12 konecne dockame alespon elementarnich replikaci, ktere budeme konfigurovat trochu vhodnejsim zpusobem nez mnozstvim insertu, patchovanim hlavniho stromu, complilovanim odstepene verze ci ja nevim cim vsim to dneska musime delat abychom dostali elementarni a ne prilis spolehlivou funkcionalitu....
Zmeny v PostgreSQL jsou spis neviditelne :-). Normalni uzivatel vyuzije predevsim inteligentnejsi optimalizator a sikovnejsi pouziti indexu. Ted hodne pouzivam plperlu a moznost zachyceni vyjimky v plpgsql se mi taky dost hodi. Ale stale je co v PostgreSQL dodelavat, chybi fura veci, replikace jsou jen jednou z nich. Bohuzel pro pristi verzi je ukol cislo jedna nahrazeni ARCu, a jak sleduji konferenci, vyvojari nemaji ted chut diskutovat o necem jinem.
