DBLog Postgres Problem

volschin · 31 Juli 2019, 00:48:00

Hallo zusammen,
cih wolle mein DBLog gern auf Postgres umstellen, soweit alles getan. Postgres läuft im Docker.
Der ConfigCheck läuft auch sauber durch, aber es können keine Werte hochgeladen werden.

Ich bin etwas ratlos.
Der Fehler im DBLog-Modul:

Code Auswählen

DBD::Pg::st execute_array failed: ERROR:  relation "history" does not exist
ZEILE 1: INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING...
                     ^ [err was 7 now 2000000000]
executing 1 generated 1 errors at ./FHEM/93_DbLog.pm line 2427.

Der Fehler im Log des Postgres:

Code Auswählen


2019-07-30 22:45:30.288 UTC [1011] ERROR:  relation "history" does not exist at character 13
2019-07-30 22:45:30.288 UTC [1011] STATEMENT:  INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES ($1,$2,$3,$4,$5,$6,$7)
2019-07-30 22:45:30.290 UTC [1011] ERROR:  relation "current" does not exist at character 8
2019-07-30 22:45:30.290 UTC [1011] STATEMENT:  UPDATE current SET TIMESTAMP=$1, TYPE=$2, EVENT=$3, VALUE=$4, UNIT=$5 WHERE (DEVICE=$6) AND (READING=$7)
2019-07-30 22:45:30.291 UTC [1011] ERROR:  relation "current" does not exist at character 8
2019-07-30 22:45:30.291 UTC [1011] STATEMENT:  UPDATE current SET TIMESTAMP=$1, TYPE=$2, EVENT=$3, VALUE=$4, UNIT=$5 WHERE (DEVICE=$6) AND (READING=$7)
2019-07-30 22:45:30.292 UTC [1011] ERROR:  relation "current" does not exist at character 8

Hat jemand den entscheidenden Tipp für mich, an welcher Schraube ich drehen muss?

Danke und Gruß
Veit

DS_Starter · 31 Juli 2019, 08:41:25

Hallo Veit,

ich selbst setze Postgres nicht produktiv ein und bin damit nicht sehr "initim".
Nach etwas googeln habe ich schnell diesen Beitrag hier gefunden der möglicherweise der Schlüssel ist:

https://stackoverflow.com/questions/36753568/postgresql-tables-exists-but-getting-relation-does-not-exist-when-querying/36753702

Hast du das Script aus https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog für die Datenbankerstellung genutzt ?

Grüße,
Heiko

volschin · 31 Juli 2019, 09:49:10

Hallo Heiko,
danke für den Hinweis. Den search path hatte ich bereits geprüft. Daran liegt es nicht.
Ich habe das Script benutzt, allerdings lief das gleich auf einen Fehler und ich musste erst eine ROLE fhem anlegen. Vielleicht habe ich dabei etwas falsch gemacht.

Ich verstehe nicht, warum das nicht Bestandteil des Scripts ist und leider auch im Wiki nicht beschrieben.

Grüße
Veit

DS_Starter · 31 Juli 2019, 10:55:34

ZitatIch verstehe nicht, warum das nicht Bestandteil des Scripts ist und leider auch im Wiki nicht beschrieben.

Vielleicht war es noch nicht aufgefallen. Bei meiner Testinstallation auf Synology hatte es mit dem Script einwandfrei geklappt.
Und soweit ich weiß, hatte sich auch noch niemand bisher beklagt. Allerdings gibt es wohl nicht so viele PostgreSQL NUtzer.
Schreib mir doch den konkreten Befehl dann füge ich es noch dem Script hinzu.

Ansonsten habe ich auch kein Patentrezept parat. Vielleicht schaut sich ein Postgre-Spezi das mal an.
Bisher war das nicht nötig und läuft auf meiner Test-DB auch einwandfrei. Die Syno hat die Version 9.3.22.

Welche Version hast du bei dir laufen ?

volschin · 31 Juli 2019, 11:10:44

Ich habe hier das aktuelle Postgres 11.4 im Docker laufen. Official Image postgres:11-alpine auf Raspi4.

Ich habe jetzt etwas entnervt die 93_DbLog.pm gehackt und überall das SCHEMA fhem vor die HISTORY und CURRENT gesetzt. Jetzt summt es, wie es soll.

Vielleicht kann man das ja mal irgendwie in das offizielle Modul aufnehmen, z.B. dass ich per Attribut die Nutzung eines Schemas definieren kann. Wenn es nicht gesetzt ist, läuft es wie bisher.

DS_Starter · 31 Juli 2019, 11:24:51

Jetzt warst du schneller als ich ... wollte dir gerade eine Testversion mit SCHEMA davor bereitstellen

ZitatVielleicht kann man das ja mal irgendwie in das offizielle Modul aufnehmen, z.B. dass ich per Attribut die Nutzung eines Schemas definieren kann. Wenn es nicht gesetzt ist, läuft es wie bisher.

Ja, werde ich machen, aber erst nach meinem Urlaub.
Bin gerade auf dem Sprung und meine bessere Hälfte war auch schon genervt dass ich hier noch "arbeite".

Btw ... eigntlich sollte das mit dem search path erledigt werden, aber so what ...

Grüße,
Heiko

volschin · 31 Juli 2019, 14:47:42

Dann schönen Urlaub und Danke.

Die Datenmigration über HeidiSQL läuft gerade. Da werden die Tabellen anscheinend sauber gefunden. Liegt dann evtl. Irgendwo in der Connection über die Perl-Bibliothek.

DS_Starter · 17 August 2019, 11:23:14

Hallo Veit,

ich habe deine Anforderung umgesetzt und bitte dich die Version bei eingehend zu testen.
Näheres hier -> https://forum.fhem.de/index.php/topic,65860.msg967523.html#msg967523

LG,
Heiko

volschin · 24 August 2019, 09:17:56

Danke, werde ich am Wochenende machen. Meine hart geänderte läuft bis jetzt bis auf ein UTF-8 Problem einwandfrei. Das hat aber nichts mit den Tabellen zu tun.

Gesendet von iPhone mit Tapatalk

Morgennebel · 26 August 2019, 17:18:00

Moin,

ich hatte dasselbe Problem bei dem Versuch, die create_db.sql für Postgres aus dem contrib anzulegen. Ich habe allerdings andere DB- und andere User-Namen verwendet und diese manuell im Script geändert - jedoch wurde die history-Tabelle nicht angelegt:

Code Auswählen


2019.08.26 15:46:50.809 1: PERL WARNING: DBD::Pg::st execute failed: ERROR:  relation "history" does not exist
LINE 6:                    FROM history WHERE 1=1 AND DEVICE  = 'SM_...
                                ^ at ./FHEM/93_DbLog.pm line 3261.

FHEM ist aktuell vom 2019-08-26.

Danke, -MN

DS_Starter · 26 August 2019, 18:43:22

Zitat
ich hatte dasselbe Problem bei dem Versuch, die create_db.sql für Postgres aus dem contrib anzulegen. Ich habe allerdings andere DB- und andere User-Namen verwendet und diese manuell im Script geändert - jedoch wurde die history-Tabelle nicht angelegt

Das hat sicherlich deswegen nicht geklappt, weil du den geänderten Usernamen nicht auch im Script Zeile 28 anstatt "fhem" eingetragen hast:

Code Auswählen


SET search_path = fhem, pg_catalog;

Der Standardsuchpfad ist nämlich gleich dem verwendeten DB-User. Wenn du im DbRep mit sqlCmd (oder einem Frontend deiner Wahl) ausführst:

Code Auswählen


SHOW search_path;

Dann bekommst du als response normalerweise das zurück:

Code Auswählen


SqlResultRow_1   "$user",public   2019-08-26 18:22:09

D.h. die Tabellen werden zuerst in einem Schema gesucht, das genauso heißt wie der User.
Seit der DbLog-Version 4.3.0 kann man mit dem attr dbSchema das zu verwendende Schema explizit setzen. Bei der Tabellenanlage muss man allerdings selbst darauf achten.

Grüße,
Heiko

Morgennebel · 26 August 2019, 19:23:03

Dein Beitrag hat mich jetzt 30 Minuten gekostet

Aber ja, Du hast recht. Den search_path hatte ich nicht angepaßt.

Darf ich vorsichtig anregen, DBUser und DBName als Parameter oder Variablen zu gestalten?

Ich habe eine Postgres-Instanz für 4 FHEM-Datenbanken (je zwei ConfigDB und LogDB) und finde "fhem/fhem" nicht sooo hilfreich.

Danke, -MN

DS_Starter · 26 August 2019, 19:32:07

ZitatDarf ich vorsichtig anregen, DBUser und DBName als Parameter oder Variablen zu gestalten?

Darfst du gerne

.
Ich bin mit dem Configfile momentan auch nicht sehr glücklich. Da gibt es zuviele Fehlermöglichkeiten.
Eigentlich habe ich geplant einen DbLog-Nachfolger zu entwerfen, der ohne Configfile arbeitet. Aber wann ich dazu mal kommen werde weiß ich nicht.
Ob die Möglichkeit, DBUser und DBName als Parameter oder Variablen zu gestalten, in dem momentanen DbLog-Layout problemlos und rückwärtskompatibel umsetztbar ist, kann ich nicht addhoc abschätzen.
Aber ich nehme es mal auf meine ToDo die Möglichkeit zu checken (die wird auch immer länger

)

Edit: mit der aktuellen Version kannst du zumindest das dbSchema-Attribut setzen um Schemas abweichend vom Standard zu setzen.

Grüße,
Heiko

volschin · 26 August 2019, 23:25:38

Zitat von: DS_Starter am 26 August 2019, 18:43:22
Das hat sicherlich deswegen nicht geklappt, weil du den geänderten Usernamen nicht auch im Script Zeile 28 anstatt "fhem" eingetragen hast:

Code Auswählen Erweitern
SET search_path = fhem, pg_catalog;

Der Standardsuchpfad ist nämlich gleich dem verwendeten DB-User. Wenn du im DbRep mit sqlCmd (oder einem Frontend deiner Wahl) ausführst:

Code Auswählen Erweitern
SHOW search_path;

Dann bekommst du als response normalerweise das zurück:

Code Auswählen Erweitern
SqlResultRow_1 "$user",public 2019-08-26 18:22:09

D.h. die Tabellen werden zuerst in einem Schema gesucht, das genauso heißt wie der User.
Seit der DbLog-Version 4.3.0 kann man mit dem attr dbSchema das zu verwendende Schema explizit setzen. Bei der Tabellenanlage muss man allerdings selbst darauf achten.

Was beim Script evtl. verwirrt, ist der Punkt das fhem keinesfalls ein User sein muss, sondern bei mir als ROLE definiert ist, die ein User hat. Das ist sauber und zulässig.
Allerdings greift dann anscheinend der searchpath nicht sauber, auch wenn man ihn ändert.

DS_Starter · 26 August 2019, 23:51:09

Zitatsondern bei mir als ROLE definiert ist, die ein User hat. Das ist sauber und zulässig.
Allerdings greift dann anscheinend der searchpath nicht sauber, auch wenn man ihn ändert.

Hab mal ein bisschen zu dem Thema gegoogelt.
Möglicherweise müsste man in dem Fall:

Code Auswählen

ALTER ROLE <your_login_role> SET search_path TO a,b,c;

verwenden. Scheint mir jedenfalls nicht abwegig.