Migrace PostgreSQL z Windows na Linux se nedaří

Prosím o radu. Používám program (AD FTK pod MS-Windows), který využívá databázi (Oracle nebo PostgreSQL), ovšem pouze vlastní instalaci na Windows. Instalace sice může být na nezávislém stroji, ale vzhledem k tomu, že používám výhradně datová úložiště (servery) s Linuxem, pokouším se migrovat PostgreSQL na Linux. Bohužel se mi to nijak nedaří. Zatím jsem sice nevyzkoušel všechny možnosti a také jsem spíše poučeným uživatelem, než datebázovým architektem a vývojářem.
Program (FTK) se prostě ke stroji MS-Windows/PostgreSQL/Python3 připojí a pracuje, ale k čisté instalaci Linux/PostgreSQL/Python3 se sice připojit pokusí a cosi tam i vykoná, ale pak to vzdá a bez vysvětlení pracovat odmítá.
Pokoušel jsem se problém řešit s oficiální podporou, ale buď to opravdu neumějí nebo umět nechtějí. Přitom na přímou otázku: zda je u nich ve firmě "Linux" sprosté slovo? se dušovali, že nikoliv.
Problém je o to složitější, že vedle standardní databáze, přístupné uživateli "postgres" si program vytvoří databázi adg, která je přístupná pouze nově založenému uživateli "adg", jehož heslo není jak získat.
Globálně jsem nějaké rozdíly odhlalil - vnitřní kódování je sice v obou případech utf-8, ale pro porovnávání je na MS/W cp1250; na Linuxu je v souboru pg_hba.conf jsem měl nastaveno "trust", ale na MS-W je požadováno "md5". Ale to mi připadá jako celkem drobné detaily s ohledem na to, že program s databází alespoň zpočátku komunikuje a zprčí se až později.
Zatím mám v plánu, po té, co zharmonisuji základní konfiguráky, podstrčit Postgresu na Linux odpovídající datový adtresář \Pgsql93\ z MS-W.
Za každý nápad budu vděčný.

Díky

Kajman:
Verzi bych mohl nainstalovat i stejnou (9.3), ale rád bych instaloval tu, která je v aktuální distribuci (9.4 nebo 9.6).
Co jsem zatím načetl, versi snad mohu i podvést, když mám lepší (u pythonu se 2.7 a 3 liší podstatně).
Zatím zápasím s tím přihlašováním, přejít z "trust" na "md5" a to jsem ještě neměl u uživatele postgres heslo zadané vůbec, to mi teď rohodilo všechny fungující procesy.
Zatím jsem si ověřil, že program (FTK) si po spuštění vytvoří nového uživatele (CREATE ROLE adg LOGIN WITH ENCRAPTED PASSWORD) a hned si tímto uživatelem vytvoří novou databázi "adg". No a té se například už nemohu vůbec zbavit?! Tedy ani toho uživatele, abych mohl tento krok zopakovat.

Keeehi:
„proxy?“
Velmi zajímavá myšlenka. Zkusím, snad bude fungovat i s PostgreSQL. Vzhledem k tomu, že mým cílem je používat program FTK, snažím se o databázích naučit pouze účelově to, co k vyřešení problému nebytně nutně budu potřebovat.

Myslel jsem, že budu moci přetáhnout existující balík s daty z Windows do Linuxového souborového systému a v pg-configu na nový adresář nasměrovat položku "data_directory=". Hm, tak snadno to asi nepůjde ;-(
Existuje pg_dumpall, ale nějak se v parametrech nemůžu dopídit zadání password (-U tam je, ale na heslo se mě nezeptá). Problém je, že to vpadá, jokoby se databáze "adg" uživatelem "postgres" nedala vydumpovat. Zkusím, ještě různé možnosti autentizace (anpříklad trust), no a uvidíme.

Zatím jsem ještě nerozchodil "proxy", ale i wiresharkem se dá ledacos odposlechnout. Zatím jsem našel nesrovnalost v parametru "LC_COLLATE" a "LC_CTYPE", což se na obou typech OS doplňuje dle místních zvyklostí (předpokládám, že se jedná o vliv LOCALES na řazení abecedy, datumy a desetiné tečky/čárky). Windowsí klient se snaží vnutit "Czech_Czech Republic.1250" na čemž SQL příkaz CREATE DATABASE okamžitě zkolabuje, protože pod Linuxem je to "cs_CZ.UTF-8". Nevím, zda lze toto nějak podvést na straně serveru, ptotože do klienta prostě nevidím. Inu kompatibilita je mocná čarodějka. Ostatně na nějakém blogu se nešťastník svěřoval, že při pg_dump(MS-W) -> pg_restore(Linux) musel, byť v angličtině, tento parametr opravit na standardní "C", a teprve pak mu zafungovalo pg_restore. Asi to bude boj, ale moc bych ho potřeboval dobojovat vítězně.

sysel:
„wireshark“
Trochu jsem se vzdělal v analytických možnostech tcpdump(u) a našel jsem možnosti, jak extrahovat SQL query pomocí CLI aplikace tshark. Takže komunikaci už vpodstatě umím odposlechnout v případě fungující komunikace program <--> pgsql(MS-Windows). Teď se pokusím totéž zajistit pro kolabující komunikaci program <--> pgsql(Linux).
-
Po několika pokusech jsem o nic moudřejší nebyl, program dokázal několikrát databázi zcela vykolejit takže "odmítá spojení" přestože běží a na portu naslouchá. Nic se nezlepšilo ani po restartu služby, ani po restartu systému. Nakonec jsem musel databázi přeinstalovat včetně kompletní likvidace všech souborů.
Vše nasvědčuje, že problém je v nastavení. Pokusil jsem se zatím "opsat" pg_hba.conf z MS-W do Linuxu. Také jsem musel nastavit alespoň nějaké heslo pro user postgres, protože programu se evidentně prázdné heslo nezdá být správně vyplněnou kolonkou. V konfiguraci postgres.conf jsem ještě zkusil změnit ssl=off, protože na MS-W nic o ssl nebylo. Ale skončil jsem opět na tom, že postgresql odmítá spojení (a to ani z řádkového klienta psql). Takže mě čeká znovu přeinstalace postgresu, protože už je nejspíš zauzlená.

Hm, tak se zdá, že bylo všechno v pečlivém nastavení konfigurací. Předně je nutné věrně napodobit pg_hba z ms-windows instalace:
V linuxové konfiguraci postgres.conf nejlépe funguje parametr:
Možná se ještě pokusím tento parametr změnit na '192.168.x.y,127.0.0.1' (někde jsem četl, že localhost je nutný). Rovněž ssl = false je dobře nebo alespoň neškodí.
Jak jsem se byl zmínil, je nutné vytvořit heslo pro uživatele "postgres", protože program při prvním připojení musí použít toto uživatelské jméno a neumožňuje odeslat prázdní heslo. To se mi podařilo v Linuxové řádce pomocí psql klienta.
Čistá instalace programu se pak konečně připojila a podařilo se jí vytvořit si své uživatele, databáze a tabulky, pomocí kterých se připojuje při dalších spuštěních.
Jedna, dosud nezmíněná součást instalace na ms-w má možná vliv, je instalace python 3, která je však na Linuxu automatická.