Fehlermeldung bei Ausführung von SQL-Kommandos

[akretschmer]

Das hat doch sogar mal geklappt... Hier die Infos über die Tabelle...

  Ungeloggte Tabelle äpublic.Stô
Spalte |  Typ  |  Attribute
--------+----------+---------------------------------------------------------
StID  | bigint  | not null Vorgabewert nextval('"St_StID_seq"'::regclass)
St  | smallint |
BlID  | bigint  | not null
Indexe:
  "St_pkey" PRIMARY KEY, btree ("StID")

Ahh, alles klar:

test=*# create unlogged table xxx (i int primary key);
CREATE TABLE
test=*# create table xxx2 (id_xxx int references xxx);
ERROR:  constraints on permanent tables may reference only permanent tables
STATEMENT:  create table xxx2 (id_xxx int references xxx);
ERROR:  constraints on permanent tables may reference only permanent tables

Das Problem hier ist das unlogged. Das ist ein neues Feature (9.2?), solche Tabellen werden nicht im WAL abgebildet. Das hat Vor- und Nachteile.

Vorteil: deutlich schneller bei schreibenden Zugriffen
Nachteile: werden nicht repliziert (das geht ja über WAL) und, ganz logisch, man kann nicht drauf referenzieren.

 

[rowJoe]

Schön das wir den Fehler haben.

Was ist genau bedeutet "unlogged" und WAL? Beides sagt mir leider nichts. Wie kann ich das Problem beheben?

[edit]
Sorry... Ich hatte gefragt ohne Google vorher zu befragen... unlogged steht im Handbuch und zu WAL gibts hier: http://tuning.postgresql.de/wal ein paar Infos

Vielen vielen Dank für deine Hilfe und die Geduld!
[/edit]

 

[akretschmer]

Schön das wir den Fehler haben.

Was ist genau bedeutet "unlogged" und WAL? Beides sagt mir leider nichts. Wie kann ich das Problem beheben?

WAL ist das Write Ahead - Log, das Transaktions-Log. Änderst Du etwas (Update ...), so wird das zuerst im WAL geschrieben. Das sind die komischen 16MB großen Dateien unterhalb von pg_xlog. Erst wenn das geschrieben ist und fsync() ausgeführt ist, gilt die Transaktion als abgeschlossen. Später werden die Änderungen dann auch in den tabellen geschrieben. Sollte vorher ein Crash sein, hat man die WAL-Files und kann alles daraus reproduzieren. Die WAL's sind auch die Grundlage für die eingebauten Replikationsmechanismen.

Bei unlogged Tables werden eben NICHT die Änderungen im WAL vermerkt. Kommt es zu einem Crash, kann die Tabelle nicht konsistent hergestellt werden. Daher gilt: nach einem Crash sind unlogged Tables komplett leer. Daher kannst Du auch keine Fremdschlüssel drauf legen, weil dann wäre die referentielle Integrität im Arsch.

Du solltest solche unlogged Tabellen als nur verwenden:

• wo es sehr schnell gehen muß
• keine Fremdschlüssel drauf liegen müssen
• ein Datenverlust schmerzfrei wäre

Klassisches Beispiel: Sessiondaten

Gefällt Dir die Antwort?

Und die Lösung wäre nun, die Tabellen nicht als unlogged anzulegen. Du mußt da irgendwo einen Schalter dafür gesetzt haben, ohne es zu bedenken.

Gefällt Dir die Lösung?

;-)

Nachtrag: man kann von unlogged Tables auf unlogged tables referenzieren. Nach einem Crash sind beide leer - das ist also konsistent.


Andreas