Re: ASCII Backup mit korrekter Reihenfolge von Objekten? (Was: Backup lässt Daten der Tabelle "times" weg)

Hallo,

ich habe mir eine kleine Mini-DB-Anwendung geschrieben, in der ich ein
paar Zeiten sportlicher Aktivitäten erfasse. In der Tabelle "times"
sind die Zeiten (und ein paar andere Parameter.) In meinem pg_dump aus
PostgreSQL 11 sind die Daten noch gefüllt. Das sollte auch noch für
PostgreSQL 12 und 13 der Fall gewesen sein, aber da habe ich die Dumps
nicht aufgehoben, aber fehlende Daten wären mir aufgefallen.

Nun stelle ich fest, dass diese eine Tabelle (und nur diese) im

pg_dump dbname

leer ist, also nur so aussieht:

COPY public.times (iddata, idstrecke, sort, "time", distance, velocity, maxvelocity, heightdiff) FROM stdin;
\.

Warum wird diese Tabelle nicht gedumpt? Ich habe mal versucht, sie in
einer testdatenbank nachzubauen und den Dump gemacht - da ist alles
drin. Woran könnte es liegen, dass PostgreSQL 14 die Tabelle leer
lässt?

Viele Grüße
Andreas.

--
http://fam-tille.de

On 7 July 2022 23:46:28 CEST, Andreas Tille <andreas(at)an3as(dot)eu> wrote:
>Hallo,
>
>ich habe mir eine kleine Mini-DB-Anwendung geschrieben, in der ich ein
>paar Zeiten sportlicher Aktivitäten erfasse. In der Tabelle "times"
>sind die Zeiten (und ein paar andere Parameter.) In meinem pg_dump aus
>PostgreSQL 11 sind die Daten noch gefüllt. Das sollte auch noch für
>PostgreSQL 12 und 13 der Fall gewesen sein, aber da habe ich die Dumps
>nicht aufgehoben, aber fehlende Daten wären mir aufgefallen.
>
>Nun stelle ich fest, dass diese eine Tabelle (und nur diese) im
>
> pg_dump dbname
>
>leer ist, also nur so aussieht:
>
>COPY public.times (iddata, idstrecke, sort, "time", distance, velocity, maxvelocity, heightdiff) FROM stdin;
>\.
>
>
>Warum wird diese Tabelle nicht gedumpt? Ich habe mal versucht, sie in
>einer testdatenbank nachzubauen und den Dump gemacht - da ist alles
>drin. Woran könnte es liegen, dass PostgreSQL 14 die Tabelle leer
>lässt?
>
>Viele Grüße
> Andreas.
>

Bitte prüfe, ob in der DB auch wirklich was in der Tabelle enthalten ist.

Andreas

--
2ndQuadrant - The PostgreSQL Support Company

Am 08.07.22 um 04:28 schrieb Andreas Kretschmer:
> On 7 July 2022 23:46:28 CEST, Andreas Tille <andreas(at)an3as(dot)eu> wrote:
>> Hallo,
>>
>> ich habe mir eine kleine Mini-DB-Anwendung geschrieben, in der ich ein
>> paar Zeiten sportlicher Aktivitäten erfasse. In der Tabelle "times"
>> sind die Zeiten (und ein paar andere Parameter.) In meinem pg_dump aus
>> PostgreSQL 11 sind die Daten noch gefüllt. Das sollte auch noch für
>> PostgreSQL 12 und 13 der Fall gewesen sein, aber da habe ich die Dumps
>> nicht aufgehoben, aber fehlende Daten wären mir aufgefallen.
>>
>> Nun stelle ich fest, dass diese eine Tabelle (und nur diese) im
>>
>> pg_dump dbname
>>
>> leer ist, also nur so aussieht:
>>
>> COPY public.times (iddata, idstrecke, sort, "time", distance, velocity, maxvelocity, heightdiff) FROM stdin;
>> \.
>>
>>
>> Warum wird diese Tabelle nicht gedumpt? Ich habe mal versucht, sie in
>> einer testdatenbank nachzubauen und den Dump gemacht - da ist alles
>> drin. Woran könnte es liegen, dass PostgreSQL 14 die Tabelle leer
>> lässt?
>>
>> Viele Grüße
>> Andreas.
>>
> Bitte prüfe, ob in der DB auch wirklich was in der Tabelle enthalten ist.
>
> Andreas

meine Vermutung: Du hast vielleicht mehrere solche Tabellen, in
unterschiedlichen Schemas.
Aber das ist nur eine Vermutung, die ich remote nicht verifizieren kann.

Andreas

--
Andreas Kretschmer
Technical Account Manager (TAM)
www.enterprisedb.com

Re: Andreas Kretschmer
> >Warum wird diese Tabelle nicht gedumpt? Ich habe mal versucht, sie in
> >einer testdatenbank nachzubauen und den Dump gemacht - da ist alles
> >drin. Woran könnte es liegen, dass PostgreSQL 14 die Tabelle leer
> >lässt?
> >
>
> Bitte prüfe, ob in der DB auch wirklich was in der Tabelle enthalten ist.

Ein häufiger Fehler ist, dass man in der falschen Datenbank schaut.
Vielleicht sind da zwei Cluster? Oder zwei Datenbanken in einem
Cluster? Oder zwei Tabellen "times" in verschiedenen Schemas?

Christoph

Hi,

Am Fri, Jul 08, 2022 at 10:04:28AM +0200 schrieb Christoph Berg:
> > Bitte prüfe, ob in der DB auch wirklich was in der Tabelle enthalten ist.

Ja, da ist was drin. Das hatte ich gerade per COPY-Befehl aus einem
alten Backup restauriert.

> Ein häufiger Fehler ist, dass man in der falschen Datenbank schaut.

Die Sache ist so simpel. Da gibt's nur eine Datenbank.

> Vielleicht sind da zwei Cluster? Oder zwei Datenbanken in einem
> Cluster?

Ich habe immer nur einen Cluster. Beim Upgrade von einer Postgres
Version auf die nächste habe ich immer die Datenbank neu angelegt.

> Oder zwei Tabellen "times" in verschiedenen Schemas?

Mit Sicherheit nicht. Es gibt in der primitiv-Anwendung nur
ein public.times ... und das bleibt halt im Backup ohne Daten
während die anderen public.* Tabellen normal gefüllt sind.

Viele Grüße
Andreas.

--
http://fam-tille.de

Am Fri, Jul 08, 2022 at 10:03:46AM +0200 schrieb Andreas Kretschmer:
>
> meine Vermutung: Du hast vielleicht mehrere solche Tabellen, in
> unterschiedlichen Schemas.
> Aber das ist nur eine Vermutung, die ich remote nicht verifizieren kann.

Ich kann den Dump auch mal irgendwohin legen - und ein Script, was bei
mir nach dem Import, dem Testen, das was drin ist, einen Export erzeugt,
wo die Daten fehlen.

Wäre jemand bereit, da zu gucken (ist wirklich eine Mini-DB mit nur
4 Tabellen und < 3000 Datensätzen.

Viele Grüße
Andreas.

--
http://fam-tille.de

Am Fri, Jul 08, 2022 at 04:20:46PM +0200 schrieb Andreas Tille:
> > Ein häufiger Fehler ist, dass man in der falschen Datenbank schaut.
>
> Die Sache ist so simpel. Da gibt's nur eine Datenbank.

Ich glaube das Problem liegt anders - ich habe offensichtlich in der Zahl
meiner Versuche die Backups verwechselt. Da wo die Daten fehlen, waren
tatsächlich die Tabellen leer und das lag an einem Fehler im restore. Ich
habe das reine Textbackup gemacht, um die Daten auch menschenlesbar zu
behalten. Beim Restore kam

FEHLER: Relation »streckeproperties« existiert nicht
ZEILE 1: SELECT sort FROM StreckeProperties WHERE sort =...
^
ANFRAGE: SELECT sort FROM StreckeProperties WHERE sort = $1
KONTEXT: PL/pgSQL-Funktion public.test_property(integer) Zeile 5 bei SQL-Anweisung

was daran liegt, dass die Tabelle StreckeProperties erst nach der Funktion

CREATE FUNCTION public.test_property(integer) RETURNS boolean
LANGUAGE plpgsql
AS $_$
Declare
Success varchar ;
BEGIN
SELECT INTO Success sort FROM StreckeProperties WHERE sort = $1 ;
IF NOT FOUND THEN
RETURN 'f' ;
ELSE
RETURN 't' ;
END IF ;
END; $_$;

im Backup auftaucht. In times wird test_property benutzt - darum bleibt
die Tabelle leer. Soweit ich mich erinnere ist in solchen Fällen das
einfache

pg_dump datenbank

nicht mehr das Mittel der Wahl. Gibt es eine Möglichkeit, einen
ASCII-Dump zu bekommen, bei dem die Relationen für einen korrekten
Import abgelegt werden?

Viele Grüße

Andreas.

--
http://fam-tille.de

On 8 July 2022 22:14:20 CEST, Andreas Tille <tille(at)debian(dot)org> wrote:
>Am Fri, Jul 08, 2022 at 04:20:46PM +0200 schrieb Andreas Tille:
>> > Ein häufiger Fehler ist, dass man in der falschen Datenbank schaut.
>>
>> Die Sache ist so simpel. Da gibt's nur eine Datenbank.
>
>Ich glaube das Problem liegt anders - ich habe offensichtlich in der Zahl
>meiner Versuche die Backups verwechselt. Da wo die Daten fehlen, waren
>tatsächlich die Tabellen leer und das lag an einem Fehler im restore. Ich
>habe das reine Textbackup gemacht, um die Daten auch menschenlesbar zu
>behalten. Beim Restore kam
>
>
>FEHLER: Relation »streckeproperties« existiert nicht
>ZEILE 1: SELECT sort FROM StreckeProperties WHERE sort =...
> ^
>ANFRAGE: SELECT sort FROM StreckeProperties WHERE sort = $1
>KONTEXT: PL/pgSQL-Funktion public.test_property(integer) Zeile 5 bei SQL-Anweisung
>
>
>was daran liegt, dass die Tabelle StreckeProperties erst nach der Funktion
>
>CREATE FUNCTION public.test_property(integer) RETURNS boolean
> LANGUAGE plpgsql
> AS $_$
> Declare
> Success varchar ;
> BEGIN
> SELECT INTO Success sort FROM StreckeProperties WHERE sort = $1 ;
> IF NOT FOUND THEN
> RETURN 'f' ;
> ELSE
> RETURN 't' ;
> END IF ;
> END; $_$;
>
>im Backup auftaucht. In times wird test_property benutzt - darum bleibt
>die Tabelle leer. Soweit ich mich erinnere ist in solchen Fällen das
>einfache
>
> pg_dump datenbank
>
>nicht mehr das Mittel der Wahl. Gibt es eine Möglichkeit, einen
>ASCII-Dump zu bekommen, bei dem die Relationen für einen korrekten
>Import abgelegt werden?
>
>Viele Grüße
>
> Andreas.
>

Die Zeiten, wo im Dump eine falsche Reihenfolge von Objekten zu Fehlern führten, sind ca. seit 10 Versionen oder mehr vorbei. Deine Funktion wird übrigens beim Restore weder ausgeführt noch compiliert oder so, daher kann das auch nicht sein. Du kannst eine Funktion auf eine nicht existente Tabelle ohne Probleme definieren, der Fehler käme erst beim ausführen.

Was mich eher irritiert ist das 'sort', das ist ein reserviertes Wort. Das schaue mir später noch mal an ..

--
2ndQuadrant - The PostgreSQL Support Company

On 9 July 2022 05:36:54 CEST, Andreas Kretschmer <andreas(at)a-kretschmer(dot)de> wrote:
>On 8 July 2022 22:14:20 CEST, Andreas Tille <tille(at)debian(dot)org> wrote:
>>Am Fri, Jul 08, 2022 at 04:20:46PM +0200 schrieb Andreas Tille:
>>> > Ein häufiger Fehler ist, dass man in der falschen Datenbank schaut.
>>>
>>> Die Sache ist so simpel. Da gibt's nur eine Datenbank.
>>
>>Ich glaube das Problem liegt anders - ich habe offensichtlich in der Zahl
>>meiner Versuche die Backups verwechselt. Da wo die Daten fehlen, waren
>>tatsächlich die Tabellen leer und das lag an einem Fehler im restore. Ich
>>habe das reine Textbackup gemacht, um die Daten auch menschenlesbar zu
>>behalten. Beim Restore kam
>>
>>
>>FEHLER: Relation »streckeproperties« existiert nicht
>>ZEILE 1: SELECT sort FROM StreckeProperties WHERE sort =...
>> ^
>>ANFRAGE: SELECT sort FROM StreckeProperties WHERE sort = $1
>>KONTEXT: PL/pgSQL-Funktion public.test_property(integer) Zeile 5 bei SQL-Anweisung
>>
>>
>>was daran liegt, dass die Tabelle StreckeProperties erst nach der Funktion
>>
>>CREATE FUNCTION public.test_property(integer) RETURNS boolean
>> LANGUAGE plpgsql
>> AS $_$
>> Declare
>> Success varchar ;
>> BEGIN
>> SELECT INTO Success sort FROM StreckeProperties WHERE sort = $1 ;
>> IF NOT FOUND THEN
>> RETURN 'f' ;
>> ELSE
>> RETURN 't' ;
>> END IF ;
>> END; $_$;
>>
>>im Backup auftaucht. In times wird test_property benutzt - darum bleibt
>>die Tabelle leer. Soweit ich mich erinnere ist in solchen Fällen das
>>einfache
>>
>> pg_dump datenbank
>>
>>nicht mehr das Mittel der Wahl. Gibt es eine Möglichkeit, einen
>>ASCII-Dump zu bekommen, bei dem die Relationen für einen korrekten
>>Import abgelegt werden?
>>
>>Viele Grüße
>>
>> Andreas.
>>
>
>Die Zeiten, wo im Dump eine falsche Reihenfolge von Objekten zu Fehlern führten, sind ca. seit 10 Versionen oder mehr vorbei. Deine Funktion wird übrigens beim Restore weder ausgeführt noch compiliert oder so, daher kann das auch nicht sein. Du kannst eine Funktion auf eine nicht existente Tabelle ohne Probleme definieren, der Fehler käme erst beim ausführen.
>
>Was mich eher irritiert ist das 'sort', das ist ein reserviertes Wort. Das schaue mir später noch mal an ..
>

Schmarrn, sort ist nicht reserviert. Es fehlt Kaffee ...

--
2ndQuadrant - The PostgreSQL Support Company

Am 09.07.22 um 05:47 schrieb Andreas Kretschmer:
> On 9 July 2022 05:36:54 CEST, Andreas Kretschmer <andreas(at)a-kretschmer(dot)de> wrote:
>> On 8 July 2022 22:14:20 CEST, Andreas Tille <tille(at)debian(dot)org> wrote:
>>> Am Fri, Jul 08, 2022 at 04:20:46PM +0200 schrieb Andreas Tille:
>>>>> Ein häufiger Fehler ist, dass man in der falschen Datenbank schaut.
>>>> Die Sache ist so simpel. Da gibt's nur eine Datenbank.
>>> Ich glaube das Problem liegt anders - ich habe offensichtlich in der Zahl
>>> meiner Versuche die Backups verwechselt. Da wo die Daten fehlen, waren
>>> tatsächlich die Tabellen leer und das lag an einem Fehler im restore. Ich
>>> habe das reine Textbackup gemacht, um die Daten auch menschenlesbar zu
>>> behalten. Beim Restore kam
>>>
>>>
>>> FEHLER: Relation »streckeproperties« existiert nicht
>>> ZEILE 1: SELECT sort FROM StreckeProperties WHERE sort =...
>>> ^
>>> ANFRAGE: SELECT sort FROM StreckeProperties WHERE sort = $1
>>> KONTEXT: PL/pgSQL-Funktion public.test_property(integer) Zeile 5 bei SQL-Anweisung
>>>
>>>
>>> was daran liegt, dass die Tabelle StreckeProperties erst nach der Funktion
>>>
>>> CREATE FUNCTION public.test_property(integer) RETURNS boolean
>>> LANGUAGE plpgsql
>>> AS $_$
>>> Declare
>>> Success varchar ;
>>> BEGIN
>>> SELECT INTO Success sort FROM StreckeProperties WHERE sort = $1 ;
>>> IF NOT FOUND THEN
>>> RETURN 'f' ;
>>> ELSE
>>> RETURN 't' ;
>>> END IF ;
>>> END; $_$;
>>>
>>> im Backup auftaucht. In times wird test_property benutzt - darum bleibt
>>> die Tabelle leer. Soweit ich mich erinnere ist in solchen Fällen das
>>> einfache
>>>
>>> pg_dump datenbank
>>>
>>> nicht mehr das Mittel der Wahl. Gibt es eine Möglichkeit, einen
>>> ASCII-Dump zu bekommen, bei dem die Relationen für einen korrekten
>>> Import abgelegt werden?
>>>
>>> Viele Grüße
>>>
>>> Andreas.
>>>
>> Die Zeiten, wo im Dump eine falsche Reihenfolge von Objekten zu Fehlern führten, sind ca. seit 10 Versionen oder mehr vorbei. Deine Funktion wird übrigens beim Restore weder ausgeführt noch compiliert oder so, daher kann das auch nicht sein. Du kannst eine Funktion auf eine nicht existente Tabelle ohne Probleme definieren, der Fehler käme erst beim ausführen.
>>
>> Was mich eher irritiert ist das 'sort', das ist ein reserviertes Wort. Das schaue mir später noch mal an ..
>>
> Schmarrn, sort ist nicht reserviert. Es fehlt Kaffee ...

So, mal nachvollzogen:

postgres=# CREATE FUNCTION public.test_property(integer) RETURNS boolean
    LANGUAGE plpgsql
    AS $_$
    Declare
    Success varchar ;
    BEGIN
      SELECT INTO Success sort FROM StreckeProperties WHERE sort = $1 ;
      IF NOT FOUND THEN
        RETURN 'f' ;
      ELSE
        RETURN 't' ;
      END IF ;
    END; $_$;
CREATE FUNCTION
postgres=# SELECT              sort FROM StreckeProperties WHERE sort= 1;
ERROR:  relation "streckeproperties" does not exist
LINE 1: SELECT              sort FROM StreckeProperties WHERE sort= ...
                                      ^
postgres=#

Wie gesagt, erstellen kann man die Funktion auch dann, wenn die Tabelle
nicht existiert, der Fehler kommt erst beim Aufruf - und beim Einspielen
des Dumps erfolgt kein Aufruf dieser Funktion.

Du hast da übrigens ein Typenproblem: die Funktion erwartet einen
INT-Parameter, dann ein select sort ... where sort = $1.
Das sollte dann also einen INT liefern, speicherst ihn aber in einem
varchar.

Aber mit Deinem Problem hat das alles nichts zu tun ...

--
Andreas Kretschmer
Technical Account Manager (TAM)
www.enterprisedb.com

On Sat, 2022-07-09 at 08:56 +0200, Andreas Kretschmer wrote:
> Wie gesagt, erstellen kann man die Funktion auch dann, wenn die Tabelle
> nicht existiert, der Fehler kommt erst beim Aufruf - und beim Einspielen
> des Dumps erfolgt kein Aufruf dieser Funktion.

Genau, denn pg_dump setzt

SET check_function_bodies = false;

Ist das im Dump enthalten?

Liebe Grüße,
Laurenz Albe

Am Sat, Jul 09, 2022 at 09:32:38PM +0200 schrieb Laurenz Albe:
> On Sat, 2022-07-09 at 08:56 +0200, Andreas Kretschmer wrote:
> > Wie gesagt, erstellen kann man die Funktion auch dann, wenn die Tabelle
> > nicht existiert, der Fehler kommt erst beim Aufruf - und beim Einspielen
> > des Dumps erfolgt kein Aufruf dieser Funktion.
>
> Genau, denn pg_dump setzt
>
> SET check_function_bodies = false;
>
> Ist das im Dump enthalten?

Der Einfachheit halber habe ich den Dump mal hierhin gelegt:

http://fam-tille.de/tmp/db/sport.dump.gz

Viele Grüße
Andreas.

--
http://fam-tille.de

On Wed, 2022-07-13 at 17:01 +0200, Andreas Tille wrote:
> Der Einfachheit halber habe ich den Dump mal hierhin gelegt:
>
>     http://fam-tille.de/tmp/db/sport.dump.gz

Damit ist alles klar.

Du hast einen CHECK-Constraint definiert, der eine Funktion aufruft, die ein SELECT
auf eine Tabelle macht.

Das darf man nicht:
/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-CHECK-CONSTRAINTS

"PostgreSQL does not support CHECK constraints that reference table data other than the new
or updated row being checked. While a CHECK constraint that violates this rule may appear
to work in simple tests, it cannot guarantee that the database will not reach a state in
which the constraint condition is false (due to subsequent changes of the other row(s)
involved). This would cause a database dump and reload to fail. The reload could fail even
when the complete database state is consistent with the constraint, due to rows not being
loaded in an order that will satisfy the constraint."

Der konkrete Anlaß für den Fehler ist, daß die Funktion die Tabelle ohne Schemanamen referenziert
und beim Restire ser "search_path" absichtlich leer ist.

Dum mußt eine andere Lösung für das Problem finden.

Liebe Grüße,
Laurenz