PostgreSQL: Abfrage zum Standort des globalen Tabellenbereichs?

Question

Ich habe versucht, unsere Datenbank-Clients proaktiv zu machen, um die Partition, auf der die Datenbank sie verwenden, nicht zu füllen.

Da alle unsere Clients auf demselben Host wie der Datenbankmanager sind, sollte es für benutzergezogene Tabellenspaces einfach genug sein. Der Client kann den Dateisystempfad für den Tablespace (in SPClocation) nachsehen und OS -Aufrufe verwenden, um zu überprüfen, wie viel verfügbarer Speicherplatz verfügbar ist:

adb=> select * from pg_tablespace;

  spcname   | spcowner |    spclocation    |       spcacl        
------------+----------+-------------------+---------------------
 pg_default |       10 |                   | 
 pg_global  |       10 |                   | 
 adb        |  2033793 | /database/adb     | {adb=C/adb}

Ich kann nicht sehen, wie vom Kunden den Weg zu dem Weg der globalen Tablespace aufbewahrt wird. In der obigen Abfrage wird eine leere Zeichenfolge zurückgegeben.

Leider haben wir viele Legacy-Systeme vor Ort, die eine bestimmte Datenbank im globalen Tablespace erstellt haben, und es wäre eine monumentale Anstrengung, sie in einen von Benutzer erstellten Tablespace zu verwandeln.

Hoffentlich fehlt mir einfach etwas wirklich Einfaches.

Answer 1

pg_default und pg_global Standorte sind "hartcodiert".

pg_default lebt in:

select setting||'/base' from pg_settings where name='data_directory';

und pg_global lebt in:

select setting||'/global' from pg_settings where name='data_directory';

src/backend/commands/tablespace.c sagt so:

 * There are two tablespaces created at initdb time: pg_global (for shared
 * tables) and pg_default (for everything else).  For backwards compatibility
 * and to remain functional on platforms without symlinks, these tablespaces
 * are accessed specially: they are respectively
 *          $PGDATA/global/relfilenode
 *          $PGDATA/base/dboid/relfilenode

Bitte beachten Sie auch, dass die Aufdeckung des Datenverzeichnisses ein - nicht so schrecklicher, aber immer noch - Sicherheitsloch ist.

app01@postgres=> show data_directory;
ERROR:  must be superuser to examine "data_directory"

Answer 2

PostgreSQL erstellt pg_default und pg_global Wenn Sie einen Cluster erstellen, möglicherweise durch Verwendung initdb direkt. Das initdb Das Dienstprogramm kann ein Argument annehmen, das das Datenverzeichnis festlegt, aber keine Argumente darüber pg_default und pg_global tablespaces.

Ich würde zu dem Schluss kommen, dass sie immer im Datenverzeichnis erstellt wurden. Ich könnte mich leicht irren. Ich glaube nicht, dass sie bewegt werden können. Darüber könnte ich mich auch irren.

Aber wenn ich bis zu diesem Punkt gleich bin, können Sie ihren physischen Standort von ableiten

show data_directory;

Das pg_global tablespace ist mit ziemlicher Sicherheit das "globale" Unterverzeichnis; pg_default Wahrscheinlich ist es auch.

Wenn ich Zeit hätte, würde ich lesen Der Quellcode. Das würde alle Zweifel entfernen.