Uneori trebuie să determinați ce fișier de pe disc corespunde tabelului. Aveți o cale plină de cifre, cum ar fi baza / 16499/19401 și doriți să o înțelegeți. Puteți să consultați mesajul de eroare care menționează numele fișierului, de exemplu:
În căutarea unui mod de atitudine
Puteți vedea calea către masă utilizând:
dar cum rămâne cu procesul invers, obținând numele obiectului din calea spre el? Există o funcție pg_filenode_relation. care pare a fi potrivită pentru acest lucru ... dar să o utilizați, trebuie să fiți conectat la baza de date specifică de care aparține acest fișier, ceea ce înseamnă că cunoașteți această conexiune.
Structura căii spre fișier
Iată cum puteți determina calea spre tabele și baze de date în versiunea modernă a PostgreSQL. (Versiunile mai vechi utilizează un format diferit, pe care îl puteți citi aici).
Există 3 moduri principale:
- Pentru fișierele din spațiul de tabelă implicit, baza / database_oid / idul fișierului pentru relația
- Pentru fișierele din alte spații de tabelă: pg_tblspc / tablespace_oid / tablespace_version_subdir / database_oid / filenode id relații
- Pentru relațiile generale: relații globale / filenode id
Relațiile generale vor fi discutate la sfârșit. Pentru primele două opțiuni, cele mai des întâlnite pe care le veți întâlni cel mai adesea, ultima parte a căii este identică, relația de bază și relația dintre oid.
Rețineți că am folosit formularea "id-ul fișierului pentru relația" și nu "relația". Acest lucru se datorează faptului că PostgreSQL are o hartă relfilenode într-un fișier numit pg_relfilenode.map pentru fiecare spațiu de bază / tabelă. Numele fișierelor de tabel nu coincid neapărat cu numele lor din pg_class. și se pot schimba după executarea VACUUM FULL, TRUNCATE și altele. De exemplu:
Ei bine, atunci. Cum să întoarceți înapoi acest nume într-un nume de relație?
Oid'y baza de date și fișiere ID-uri relații
Să presupunem că ați primit o eroare de la începutul acestui articol. Acesta poate fi împărțit în mai multe părți:
- bază: în spațiul de tabelă implicit
- 16396: în baza de date cu oid'om 16396
- 3720450 id de fișier pentru un tabel cu o valoare 3720450
apoi luați în considerare ceea ce înseamnă fiecare dintre ele.
Definiția bazei de date de către oid
În primul rând, trebuie să vă conectați la orice bază de date în acest proces PostgreSQl și să executați:
(sau orice altă bază de bază pe care o aveți). Acest lucru vă va oferi numele bazei de date.
După aceasta, trebuie să vă conectați la această bază de date.
Reverse conversia lui relfilenodes la versiunea 9.4
Dacă utilizați versiunea 9.4 sau mai recentă, atunci pentru dvs. partea următoare este simplă:
(0 înseamnă "spațiu de tabelă implicit")
Această funcție efectuează conversia inversă a relfilenode pentru dvs. Deci, vă arată doar numele mesei. Nu va afișa un link la nicio schemă dacă numele tabelului rezultat aparține trasei curente de căutare; Puteți utiliza SET search_path = ''; înainte de a executa funcția, pentru ca calea să fie specificată până la schemă.
Trebuie să fiți conectat la baza de date corectă sau să primiți un răspuns incorect sau să nu primiți niciun răspuns.
Conversia inversă a lui relfilenodes la versiunea 9.3
Dacă utilizați versiunea 9.3 sau mai veche, trebuie să vă conectați la baza de date în care se află tabela și să executați următoarea interogare la pg_class:
(sau oricare alt id de relfilenode primit al tabelului).
Aceasta vă va spune la ce tabel aparține această eroare.
Niciun rezultat?
De obicei, ajută.
Relfilenode poate fi, de asemenea, zero, aceasta înseamnă că fișierul este localizat prin pg_relfilenode.map. Acesta este un scenariu tipic pentru cataloage generale și unele cataloage de sistem, indici, tabele TOAST etc. De exemplu, aceasta poate fi pg_database. pg_class și pg_proc.
Cum rămâne cu schema?
Ați observat că schema (spațiul de nume) nu apare în cale?
Schema PostgreSQL este doar un spațiu de nume în cadrul bazei de date. Ele nu au niciun efect asupra locului în care sunt stocate fizic tabelele de pe disc.
Alte modalități de spații de masă
Incidentul recent pe care l-am întâlnit a fost următoarea eroare:
Acesta nu este spațiul de tabelă implicit, deoarece calea începe cu pg_tblspc.
Însuși procesul de găsire a mesei este de fapt același. Puteți ignora partea pg_tblspc / nnn / PG_n.n_nnnnnn / și puteți focaliza imediat pe database_oid / relation_oid. așa cum este descris mai sus pentru cazurile cu un spațiu de tabel implicit. Pentru aceasta, merită înțeleasă ce înseamnă calea.
Astfel, textul de eroare este împărțit în următoarele părți:
Am discutat deja despre partea despre baza de date și id-ul relfilenode tabular. Ele nu diferă de spațiul tabelului, ci încep doar în altă parte.
Și ce zici de partea cu spațiul tabelului?
Oid se referă la intrarea pg_tablespace pentru spațiul de masă, după cum se vede din:
În directorul spațiului de tabelă există un alt director numit după versiunea PostgreSQL. Este static pentru această versiune și singura aplicație pentru aceasta este accesul multiplu al mai multor procese PostgreSQL la un spațiu de tabelă, de exemplu, în timpul pg_upgrade. De regulă, există doar o înregistrare.
În general, structura este aceeași ca și pentru baza / căile - mai întâi oidele bazei de date, apoi oidele relației.
Tabele globale (partajate)
Căile spre ele încep cu globul în loc de bază și nu au o componentă cu baza de date.
Comenzile obișnuite nu marchează relfilenode în pg_class. Adică, nu puteți vedea, de exemplu, pg_database din pg_class. pg_filenode_relation returnează null, indiferent dacă se numește cu oid din spațiul tabelă implicit sau cu oid din spațiul tabel global 1664.
Explicarea acestui lucru este subiectul articolului următor cu link-urile dezasamblate.
Desigur, dacă întâmpinați probleme cu directoarele comune, probabil că nu veți putea începe în principiu baza de date.
Se ocupă de daune
Deteriorarea bazei de date nu ar trebui să se întâmple. Dar se poate întâmpla în orice caz. Acestea pot fi probleme cu hardware-ul, bug-urile kernel-ului sau sistemele de fișiere, SSD-urile care se referă la crearea unor fluxuri de discuri de încredere, rețelele de stocare buggy și, bineînțeles, PostgreSQL. Dacă bănuiți că ați deteriorat baza de date, înainte de a face ceva, citiți și urmați sfatul paginii wiki pentru pagube.
interioare
Pentru a vedea cum funcționează toate, rulați macrola relpathbackend în src / include / common / relpath.h. Se numește GetRelationPath în src / common / relpath.c.
Trimiteți-le prietenilor: