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:
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:
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
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
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
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 ?
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.
Jetzt warst du schneller als ich ... wollte dir gerade eine Testversion mit SCHEMA davor bereitstellen 8)
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
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.
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
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
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:
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
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:
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:
SHOW search_path;
Dann bekommst du als response normalerweise das zurück:
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
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
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
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:
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:
SHOW search_path;
Dann bekommst du als response normalerweise das zurück:
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.
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:
ALTER ROLE <your_login_role> SET search_path TO a,b,c;verwenden. Scheint mir jedenfalls nicht abwegig.
Hallo Zusammen,
mir ist leider vor 2 Tagen scheinbar der Speicher vollgelaufen und ich habe nicht aufgepasst. Einzige Möglichkeit war dann irgendwie nur noch die Datenbank zurück zu setzen. Jetzt hänge ich leider vor dem Problem, dass ich sie nicht mehr konfiguriert bekomme. Ich hoffe mir kann jemand helfen, da ich die folgende Fehlermeldung bekomme:
DbLog logdb - DBI connect('database=fhem;host=localhost','fhem',...) failed: FATAL: Datenbank »fhem« existiert nicht at ./FHEM/93_DbLog.pm line 3085.
Ausgeführt habe ich:
CREATE USER fhem PASSWORD 'geheim';
\i /opt/fhem/contrib/dblog/db_create_postgresql.sql
Nachträglich habe ich auch nochmal dies danach ausgeführt:
SET search_path = fhem, pg_catalog;
Leider ohne Erfolg. Mich wunder nur, dass in dem Script gar keine Datenbank angelegt wird :) Trotzdem hoffe ich, dass jemand eine Idee hat
Okay, ich habe es wieder zum Laufen gebracht, aber ein paar Sachen erschließen sich mir noch nicht.
Folgendes
CREATE DATABASE fhem OWNER fhem;
\c fhem #um in die Datenbank zu gehen
\i /opt/fhem/contrib/dblog/db_create_postgresql.sql
ein zweites Ausführen des Scriptes macht natürlich keinen Sinn, sorgt aber dafür, dass die Tabellen nochmal in der neu angelegten Datenbank angelegt werden und fhem somit wieder drauf zufgreifen kann.
Ich schau mal ob man das Script umschreiben kann.
Was sich mir aber nicht erschließt ist, dass sich der SET search_path über das Script nicht aktiviert. Diesen musste ich händisch nochmal ausführen - oder wird dieser automatisch wieder zurück gesetzt?
Wo hast du das verwendete Script her ?
Das offiziell in der CommandRef verlinkte Script sieht so aus:
--
-- PostgreSQL database dump
--
SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;
--
-- Name: fhem; Type: SCHEMA; Schema: -; Owner: fhem
--
CREATE SCHEMA fhem;
ALTER SCHEMA fhem OWNER TO fhem;
--
-- Name: SCHEMA fhem; Type: COMMENT; Schema: -; Owner: fhem
--
COMMENT ON SCHEMA fhem IS 'standard fhem schema';
SET search_path = fhem, pg_catalog;
SET default_tablespace = '';
SET default_with_oids = false;
--
-- Name: current; Type: TABLE; Schema: fhem; Owner: fhem; Tablespace:
--
CREATE TABLE current (
"timestamp" timestamp without time zone,
device character varying(64),
type character varying(64),
event character varying(512),
reading character varying(64),
value character varying(128),
unit character varying(32)
);
ALTER TABLE fhem.current OWNER TO fhem;
--
-- Name: history; Type: TABLE; Schema: fhem; Owner: fhem; Tablespace:
--
CREATE TABLE history (
"timestamp" timestamp without time zone default CURRENT_TIMESTAMP,
device character varying(64),
type character varying(64),
event character varying(512),
reading character varying(64),
value character varying(128),
unit character varying(32)
);
ALTER TABLE fhem.history OWNER TO fhem;
--
-- Name: reading; Type: INDEX; Schema: fhem; Owner: fhem; Tablespace:
--
CREATE INDEX "Search_Idx" ON history USING btree (device, reading, "timestamp");
--
-- PostgreSQL database dump complete
--
Dort finde ich die von dir zitierte Sequenz nicht:
CREATE DATABASE fhem OWNER fhem;
\c fhem #um in die Datenbank zu gehen
\i /opt/fhem/contrib/dblog/db_create_postgresql.sql
Genau das hatte ich zuerst verwendet. Liegt ja hier:
/opt/fhem/contrib/dblog/db_create_postgresql.sql
Allerdings meldet mir fhem dann, dass es die Datenbank nicht finden kann. Wenn ich in psql allerdings die Datenbank mit den Tabellen wie beschrieben anlege funktioniert es. In dem Script wird ein Schema angelegt. Dies kann ich aber weder finden, noch irgendwo die Tabellen. Deswegen war meine Überlegung: Wenn fhem eine Datenbank fehlt, dann gib ihm eine :)
Klingt einleuchtend. Interressant dass es bisher nur diese eine Meldung mit diesem Bezug gibt wenn ich nicht irre.
Bin nicht so familiär mit Postgre ... sollte ich mir vllt. mal genauer anschauen bei Gelegenheit.
Ich leider auch nicht und ganz verstehe ich das vorgehen selbst nicht. Ich hatte eben nochmal versucht die Datenbank anzulegen, in die Datenbank abzuspringen und dann das Script laufen zu lassen. Tabellen werden Angezeigt, fhem meldet dann aber einen Connection Error über Localhost und den Port.
Ich bekomme beim zweiten Durchlauf des Sciptes in der Datenbank auch keine Fehlermeldung, dass die Schemas schon existieren - macht für mich so irgendwie auch keinen sinn.
Wenn du mal eine Erklärung findest und auch ein aufs erste funktionierendes Skript, bitte gerne Bescheid geben :) .. bei mir scheint es jetzt wohl zu funktionieren, aber wissenstechnisch komme ich hier nicht weiter :P
Mach ich gerne. Als ich vor langer Zeit mit der Weiterentwicklung von DbLog begonnen hatte, hab ich ich auf meiner Synology die Postgre - Testdatenbank mit diesem Script angelegt. Hat wohl auch geklappt, sonst hätte ich es wahrscheinlich angepasst.
Aber sicher bin ich mir nicht nach so langer Zeit ob ich nicht doch noch dabei nachgeholfen hatte. ;)
Mittlerweile ist man ja auch bei pgsql 13.x. Da muss man schon fragen, mit welcher Version was nicht funktioniert.