Pozorování: data type unknown v tabulce a upgrade

[Michal Valenta]

Ahoj,
stalo se něco, co mě překvapilo, tak dávám do placu, jestli nemáte
třeba někdo podobnou zkušenost nebo mi vysvětlíte, jak k tomu mohlo
dojít.

Kolega upgradoval server z 9.6 na verzi 13. Při tom udělal export dat a
následný import do upgradovéného clusteru.

Pak se zjistilo, že několik schémat v mé (migrované) databázi má
prázdné tabulky. První, co se ukázalo při hledání příčiny bylo toto:

CREATE TABLE uvazky_b181.navrh_zmen_uvazku (
jmeno character varying(50),
prijmeni character varying(50),
...
novy_pomer unknown,
...
);

Teď záhady:

1. Netuším, jak se mi podařilo takovou tabulku vytvořit. Napadá mě, že
jsem mohl udělat něco jako
create table ... as select ....
a v tam mohlo dojít ke špatnému odvození datového typu. Ale vědom si
toho nejsem.

2. Proč tohle způsobilo, že několik dalších schémat v pořadí importu
uvazky_b182 a ještě dvě mají také prázdné tabulky, poslední dvě v řadě
- uvazky_b201 a uvazky_b202 už jsou v pohodě.

No, doufám, že to bylo jenom tímto.

Není to fatální, relativně snadno to opravíme, ale budu rád za nějaké
případné nápady a poznámky k tomu.

Michal

[Jan Michálek]

To je upgradované pomocí pg_upgrade, nebo z restore dumpu? Jak vypadá ta původní tabulka? Jaký je datový typ atributu "novy_pomer"?

Zrovna včera jsem letmo koukal na release notes ke 13 (taky zvažuju upgrade z 9.6 - ale 59kal jsem si, že počkám ještě na jednu minor verzi) a všiml jsem si, že tam byla nějaká změna k uživatelsky definovaným typům. Kdybych to řešil já tak bych zapátral tímto směrem (jestli se třeba nemohlo stát, že se nevytvořil správně kompozitní typ, nebo enum - například byl ve špatném schématu). Další změny, co jsem si tam všiml, byly vztažené k jsonb, jestli se nepletu. Tak to je tip číslo dvě.

Je;

st 12. 5. 2021 v 10:08 odesílatel Michal Valenta <michal.n...@gmail.com> napsal:

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/c6634f1441e055bd1d09d020d90577a41795c53f.camel%40gmail.com.

--

Jelen

Starší čeledín datovýho chlíva

[Pavel Stehule]

st 12. 5. 2021 v 10:08 odesílatel Michal Valenta <michal.n...@gmail.com> napsal:

Ahoj,

  stalo se něco, co mě překvapilo, tak dávám do placu, jestli nemáte
třeba někdo podobnou zkušenost nebo mi vysvětlíte, jak k tomu mohlo
dojít.

Kolega upgradoval server z 9.6 na verzi 13. Při tom udělal export dat a
následný import do upgradovéného clusteru.

Pak se zjistilo, že několik schémat v mé (migrované) databázi má
prázdné tabulky. První, co se ukázalo při hledání příčiny bylo toto:

CREATE TABLE uvazky_b181.navrh_zmen_uvazku (
    jmeno character varying(50),
    prijmeni character varying(50),
    ...
    novy_pomer unknown, 
    ...
);

Tohle je mozna nejaka archaicka chyba - ponevadz tabulku s typem unknown uz ted nevytvoris. i create table as select mi misto unknown vytvori sloupec text.

V te 9.6 to bylo jako unknown? Ten unknown typ je rozhodně nějaká chyba

 

Teď záhady:

1. Netuším, jak se mi podařilo takovou tabulku vytvořit. Napadá mě, že
jsem mohl udělat něco jako
create table ... as select ....
a v tam mohlo dojít ke špatnému odvození datového typu. Ale vědom si
toho nejsem.

v 9.6 to teoreticky lze

postgres=# create table xx(a unknown);
WARNING:  column "a" has type "unknown"
DETAIL:  Proceeding with relation creation anyway.
CREATE TABLE
postgres=# \d xx
       Table "public.xx"
┌────────┬─────────┬───────────┐
│ Column │  Type   │ Modifiers │
╞════════╪═════════╪═══════════╡
│ a      │ unknown │           │
└────────┴─────────┴───────────┘

ale neco takoveho vidim prvne v zivote

 

2. Proč tohle způsobilo, že několik dalších schémat v pořadí importu
uvazky_b182 a ještě dvě mají také prázdné tabulky, poslední dvě v řadě
- uvazky_b201 a uvazky_b202 už jsou v pohodě.

No, doufám, že to bylo jenom tímto.

Není to fatální, relativně snadno to opravíme, ale budu rád za nějaké
případné nápady a poznámky k tomu.

mas jeste k dispozici ten dump?

pg_dump v defaultu ignoruje chyby. Pokud je ale z nejakeho duvodu dump naboreny, tak se nepovede ta prvni operace, a pak treba ani nasledna nez se spravne chytne zacatek prikazu. COPY se neukoncuje strednikem, ale \. - a pokud nekde pri importu se nahlasi chyba, tak vsechny dalsi prikazy do dalsiho stredniku asi budou rozbity (pokud pouzivas SQL dump).

dobrou praktikou pri nacitani dat z pg_dumpu je neignorovat chyby (pokud je nacitas skrz psql)

psql -v ON_ERROR_STOP=1

[Josef Capek, DATONA]

Michale
když při restore přesměruješ chybový výstup do souboru tak v něm
většinou najdeš jasně popsanou příčinu.

Např. takto:
pg_restore -h server -d nazev_db soubor_se_zalohou 2>chybovy_vystup.log

Pepa


Hezký den
Josef Čapek, DATONA s.r.o.
tel. 603 430 733

[David Turoň]

ja jsem to tusim zahledl, myslim ze to bylo view a nejaky vyraz bez pretypovani - ale uz si nevzpomenu co presne to bylo a ted se mi to nedarilo vyvolat.

David

st 12. 5. 2021 v 10:08 odesílatel Michal Valenta <michal.n...@gmail.com> napsal:

Ahoj,

[David Turoň]

oprava - byla to tabulka vytvorena jako CREATE TABLE x AS SELECT, ale puvodni select nemam a uz pred dumpem byl typ unknown ..., pri restore WARNING

David

čt 13. 5. 2021 v 7:40 odesílatel David Turoň <turon...@gmail.com> napsal: