vystup pgdump (meta data v komentarich)

16 views
Skip to first unread message

Michal Bartak

unread,
Apr 10, 2024, 10:03:28 AMApr 10
to postgr...@googlegroups.com

Ahoj
Cely email je dost dlouhy. Rozdelil jsem ho na dve casti: prvni kratkou, z otazkou na kterou odpoved mne zajima, a druhou pro ty co jsou zvedavi a maji dostatek trpelivosti :)

Jedna se o obsah plain vystupu z pgdump/pdumpall. Obsahuje on meta data dumpovanych objektu (ktere nekdo by mohl chtit pouzit pro nejake automatizovane potreby). 

Treba:

--
-- Name: tab_clients; Type: TABLE; Schema: clients; Owner: sazky
--   


Narazil jsem tu na jiste nedostatky. A to:
1. nekonzistentni podoba seznamu argumentu funkci v komentarich/meta informacich
2. nazvy objektu nejsou escapovany/zabaleny do uvozovek, i v pripade ze obsahuji mezery.
3. chybejici nazev tabulky pro vytvareny index v meta informacich 

Otazka:
Kde muzu tohleto reportovat abych zvetsil sanci na pripadnou opravu?

Nalez byl odhalen behem psani nastroje, ktery rozpada vystup generovany pg_dump/pg_dumpall na jednotlive soubory cilem dalsiho verzovani v GIT.
https://github.com/michalk-k/pgdump_splitter

#### Pro ty co se chteji seznamit s detailem problemu ####

A. Nekonzistentni identifikator funkce

DDL funkce predchazi nize uvedeny blok komentare.
Argumenty funkce jsou identifikovane pouze datovymi typy, co odpovida tomu co najdeme v pg_proc.oid::regprocedure (nebo presneji oidvectortypes(pg_proc.proargtypes))
--
-- Name: quote_empty(character varying, integer[]); Type: FUNCTION; Schema: public; Owner: sazky
-- 

Ale uz v pripade ACL, identifikator muze (nemusi ale) obsahovat nazvy argumentu
--
-- Name: FUNCTION generate_salt(_length integer); Type: ACL; Schema: betsys; Owner: sazky
--


--
-- Name: FUNCTION ghstore_out(public.ghstore); Type: ACL; Schema: public; Owner: sazky
-- 

Pokud to neni malo, pak pripadne output parametry jsou indikovane klicovym slovem OUT
--
-- Name: FUNCTION dblink_get_notify(conname text, OUT notify_name text, OUT be_pid integer, OUT extra text); Type: ACL; Schema: public; Owner: sazky
-- 


Prani c. 1: konzistentni format argumentu funkci v meta informacich. Nejlip totozne s oidvectortypes(pg_proc.proargtypes)


B. chybejici guoting  nazvu objektu obsahujicich mezery (ale take nevzdycky)

--
-- Database "db s mezerou" dump
--
Vyse je to spravne, uz par radek nize nikoliv:
--
-- Name: db s mezerou; Type: DATABASE; Schema: -; Owner: postgres
-- 


Jeste horsi je to u tabulky, a hlavne jeji atributu a navaznych vlastnosti:

CREATE TABLE "schema s mezerou"."table s mezerou" (
    "id s mezerou" bigint NOT NULL
);


V dumpu najdeme nasledujici bloky komentaru:
Vytvoreni tabulky
--
-- Name: table s mezerou; Type: TABLE; Schema: schema s mezerou; Owner: postgres
--

ACL tabulky, prekvaplive jen pro nazev tabulky. Nazev schematy uz nikoliv:
--
-- Name: TABLE "table s mezerou"; Type: ACL; Schema: schema s mezerou; Owner: postgres
-- 
 

Nazev sekvence
--
-- Name: table s mezerou_id s mezerou_seq; Type: SEQUENCE; Schema: schema s mezerou; Owner: postgres
-- 

ACL sekvence je podobne spravne jako u ACL tabulky:
--
-- Name: SEQUENCE "table s mezerou_id s mezerou_seq"; Type: ACL; Schema: schema s mezerou; Owner: postgres
--

EXTREM je pro default sloupce v tabulce. Tady neni mozne rozlisit co je nazev tabulky a co je nazev sloupce.
--
-- Name: table s mezerou id s mezerou; Type: DEFAULT; Schema: schema s mezerou; Owner: postgres
-- 

Prani c. 2 Dodrzovani konvenci nazvu objektu v meta datech/komentarich v plain dumpu

Nakonec uz malickost. Meta info pro indexy neobsahuje nazev tabulky ke ktere index patri. Coz je nekonzistentni s jinymi pripady , np. nazev tabulky, ke ktere patri komentar ke sloupci ;)
--
-- Name: ix_tabuserroles_idrole; Type: INDEX; Schema: app_permissions; Owner: sazky
--

CREATE INDEX ix_tabuserroles_idrole ON app_permissions.tab_user_roles USING btree (id_role);

Zdravim vsechny
                                                                                               

Pavel Stehule

unread,
Apr 10, 2024, 3:05:04 PMApr 10
to postgr...@googlegroups.com
Ahoj

st 10. 4. 2024 v 16:03 odesílatel Michal Bartak <maxym...@gmail.com> napsal:

Ahoj
Cely email je dost dlouhy. Rozdelil jsem ho na dve casti: prvni kratkou, z otazkou na kterou odpoved mne zajima, a druhou pro ty co jsou zvedavi a maji dostatek trpelivosti :)

Jedna se o obsah plain vystupu z pgdump/pdumpall. Obsahuje on meta data dumpovanych objektu (ktere nekdo by mohl chtit pouzit pro nejake automatizovane potreby). 

Treba:

--
-- Name: tab_clients; Type: TABLE; Schema: clients; Owner: sazky
--   


Narazil jsem tu na jiste nedostatky. A to:
1. nekonzistentni podoba seznamu argumentu funkci v komentarich/meta informacich
2. nazvy objektu nejsou escapovany/zabaleny do uvozovek, i v pripade ze obsahuji mezery.
3. chybejici nazev tabulky pro vytvareny index v meta informacich 

Otazka:
Kde muzu tohleto reportovat abych zvetsil sanci na pripadnou opravu?

ted uz asi nejlepe v pgsql-hackers - a pokud prilozis patch s opravou, tak tim sanci zvysis na maximum :-). Tohle je oprava generovanych komentaru, tak by tam asi nemel byt zavaznejsi problem
Urcite by tam mela byt nejaka konzistence. O tom neni pochyb. Predpokladam, ze ale komentare jsou v nejake historicke podobe, jak to kdo naprgal, a pravdepodobne se ani netestuji. Pro pgdump jsou dost masivni regresni testy, ale nevsiml jsem si, ze by byly testovane komentare. Asi nikoho nenapadlo, ze by komentare mohly byt k necemu uzitecne. Je otazkou jestli tu cast, ktere generuje komentare neprepsat z gruntu, aby komentare byly vzdy konzistentni. 

Pavel
                                                                                               

--
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 tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAAVzF_HUmNtfnR7D9XFF-S8kZXhku2uurgbdnitE-eyrn0LOHg%40mail.gmail.com.

David Turoň

unread,
Apr 11, 2024, 1:27:18 AMApr 11
to postgr...@googlegroups.com
Ahoj

Me se na tohle osvedcil nastroj pg_extractor https://github.com/omniti-labs/pg_extractor, ale vytahuje to z zive DB. Ale urcite chapu, ze existuji jine use case kdy to potrebujes dostat z dumpu nebo mozna tam chces doplnit nejake informace navic apod...

Vetsinou nejake neverzovane veci jsem stahl pres pg_extractor - ten to rozseka na soubory - tabulky, funkce, typy apod. a pak uz to udrzujeme pres nas nastroj pgdist https://github.com/linuxbox-cz/pgdist.

Mozna nejaka jednodussi cesta by byla mit binarni dump (ale treba nemas tu moznost), z neho nalit jen schema na nejakou devel DB a ty informace si vycist primo tam ...

treba pro funkce:
SELECT pg_get_function_arguments ('public.test'::regproc); --nebo iterace pres oid z systemoveho katalogu

test=# SELECT pg_get_function_arguments ('public.test'::regproc);
           pg_get_function_arguments          
-----------------------------------------------
 a text DEFAULT 'a'::text, b integer DEFAULT 0
(1 řádka)

a parsovat to z toho ...

David

st 10. 4. 2024 v 16:03 odesílatel Michal Bartak <maxym...@gmail.com> napsal:


Michal Bartak

unread,
Apr 11, 2024, 5:53:01 AMApr 11
to postgr...@googlegroups.com
Diky
My to dumpujeme prave z db dostupne pro tento ucel (docker na stole nebo v GitLabu - je to soucast nasi development pipeliny). Doposud jsme pouzivali obdobu extraktora, napsanou pro tyto ucely asi pred 15 lety.
Jen porad vznikala potreba upravovani ho pro support novych veci.
Zvolili jsme vysup z pg_dumpall kvuli zaruce ziskani kompletniho setu objektu a jejich vlastnosti s kazdou novou verzi db, bez nutnosti upravovani extraktora. 

Jinak jsem se zbezne podival na podobne tooly, a ani mne neprekvapilo ze dokazaly zkolabovat s nasi db. Na priklad v pripade fuknci s velkym poctem argumentu, nedokazaly vytvorit soubor kvuli prilis dlouhe delce jeho nazvu ;) 
Nektere tooly ignoruji pro nas klicove veci. Na priklad nastaveni konf parametru pro jednotlive objekty (databaze, role apod). Jine dumpuji databaze, nikoliv cluster, apod.

Dalsi motivaci bylo zrychlit tu extrakci (u nas to je cca 7-10x zrychleni oproti predchozimu reseni), poskytnout multiplatformni buildy a pro mne vyzkouset si golang ;)

čt 11. 4. 2024 v 7:27 odesílatel David Turoň <turon...@gmail.com> napsal:

Michal Bartak

unread,
Apr 11, 2024, 5:55:28 AMApr 11
to postgr...@googlegroups.com
Diky Pavle
Podivam se do zdrojaku, zda je to v mych silach. Uprava zda se trivialni (resp. ta nevyzadujici vetsi refaktoring)
Prip napisu na pgsql-hackers. Videl jsem ze je provozovano vetsi mnozstvi diskuznich skupin. Dobre vedet ze ta konkretni je ta spravna.

Michal

st 10. 4. 2024 v 21:05 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

David Turoň

unread,
Apr 11, 2024, 6:45:57 AMApr 11
to postgr...@googlegroups.com
jj, jasne chapu:), drzim palce at se povede sjednotit ty docstringy v dumpech.

Me zase treba u pg_dumpall chybel ten binarni format, tak jsem si pred casem napsal skriptik pro dump vsech databazi a roli a taky nastaveni DB - treba vice jobu a do directory formatu apod, to mi u pg_dumpall chybelo. Ale ted lezi nekde ladem, protoze stejne vetsinou jsem potreboval resit jednu DB pripadne pro nejake interni zalohy mame zase nejake ruzne prominky exvludu pro ruzne databaze apod...

David

čt 11. 4. 2024 v 11:53 odesílatel Michal Bartak <maxym...@gmail.com> napsal:

Michal Bartak

unread,
Apr 11, 2024, 7:56:35 AMApr 11
to postgr...@googlegroups.com
No... ono ta motivace momentalne je mensi nez 100%, protoze nase konvence zakazuji pouzivani mezer, uppercasu nebo jinych divnych znaku v nazvech. A v pripade indexu jsem si tu chybejici tabulku vyndal ze samotneho DDL. TImto aktualni verze splitteru pokryva nase potreby. 
Ale pokusim se alespon zahajit topic na plsql-hackers - minule jsem potreboval rok abych zareportoval bug ;) 
I kdyz laka mne take podivat se do zdrojaku pgdumpu... 

Michal

čt 11. 4. 2024 v 12:45 odesílatel David Turoň <turon...@gmail.com> napsal:
Reply all
Reply to author
Forward
0 new messages