Hallo,
es gibt ja hier den einen oder anderen, der PostgreSQL macht. Ich habe da etwas, was ich für komisch halte. Es handelt sich um 8.1.11 als Server - ist nicht mehr das Neueste, ich weiß, aber es ist ein SLES und da muß es super sein ...
psql> CREATE TABLE a1 (id BIGSERIAL PRIMARY KEY, name TEXT); psql> \d+ a1 Column | Type | Modifiers | Description --------+--------+-------------------------------------------------+------------- id | bigint | not null default nextval('a1_id_seq'::regclass) | name | text | | Indexes: "a1_pkey" PRIMARY KEY, btree (id) Has OIDs: no
Wenn ich das per pg_dump ausspucke, kommt da erwartungsgemäß die Table-Definition und dann im Dump noc hein ein
ALTER TABLE ONLY a1 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);
Soweit so gut.
Jetzt habe ich die Tabelle und auch den Index umbenannt:
psql> ALTER TABLE a1 RENAME TO a2; psql> ALTER INDEX a1_pkey RENAME TO a2_pkey; psql> \d+ a2 Column | Type | Modifiers | Description --------+--------+-------------------------------------------------+------------- id | bigint | not null default nextval('a1_id_seq'::regclass) | name | text | | Indexes: "a2_pkey" PRIMARY KEY, btree (id) Has OIDs: no
Sieht auch noch gut aus, Tabelle und Index haben neue Namen. Jetzt aber im pg_dump, erscheint immer noch
ALTER TABLE ONLY a2 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);
Und mein a2_pkey wird nirgens erwähnt.
Bug oder Feature? Oder mache ich etwas falsch? Am "pg_dump" scheint es nicht zu liegen, wenn ich auf einer anderen Maschine ein pg_dump (8.3.6) nehme, dann ist das genauso falsch, außer ich mache das o.a. Experiment auch mit dem 8.3.6 Server, dann ist es, wie ich's erwartet hätte.
Viele Grüße Heiko
In response to Heiko Schlittermann :
[ Lustiges mit einer alten PG-Version ]
Bug oder Feature? Oder mache ich etwas falsch? Am "pg_dump" scheint es nicht zu liegen, wenn ich auf einer anderen Maschine ein pg_dump (8.3.6) nehme, dann ist das genauso falsch, außer ich mache das o.a. Experiment auch mit dem 8.3.6 Server, dann ist es, wie ich's erwartet hätte.
Bug, denk ich mal. Es steht falsch in pg_constraint, aber richtig in pg_class. Daher kann auch pg_dump es nicht richtig machen.
Ich erlaube mir mal, das in die deutsche PG-Mailingliste zu leiten, okay?
Andreas
Andreas Kretschmer andreas.kretschmer@schollglas.com (Do 19 Mär 2009 11:24:14 CET):
In response to Heiko Schlittermann :
[ Lustiges mit einer alten PG-Version ]
Bug oder Feature? Oder mache ich etwas falsch? Am "pg_dump" scheint es nicht zu liegen, wenn ich auf einer anderen Maschine ein pg_dump (8.3.6) nehme, dann ist das genauso falsch, außer ich mache das o.a. Experiment auch mit dem 8.3.6 Server, dann ist es, wie ich's erwartet hätte.
Bug, denk ich mal. Es steht falsch in pg_constraint, aber richtig in pg_class. Daher kann auch pg_dump es nicht richtig machen.
Ich erlaube mir mal, das in die deutsche PG-Mailingliste zu leiten, okay?
Ja. Danke.
Vielleicht noch Informationen zum Hintergrund... Andreas Kretschmer andreas.kretschmer@schollglas.com (Do 19 Mär 2009 11:24:14 CET):
In response to Heiko Schlittermann :
[ Lustiges mit einer alten PG-Version ]
Bug oder Feature? Oder mache ich etwas falsch? Am "pg_dump" scheint es nicht zu liegen, wenn ich auf einer anderen Maschine ein pg_dump (8.3.6) nehme, dann ist das genauso falsch, außer ich mache das o.a. Experiment auch mit dem 8.3.6 Server, dann ist es, wie ich's erwartet hätte.
Bug, denk ich mal. Es steht falsch in pg_constraint, aber richtig in pg_class. Daher kann auch pg_dump es nicht richtig machen.
Das Projekt lebt, bei Schemaänderungen können wir nicht immer einfach die Datenbank wegschmeißen und neu bauen, also gibt's bei Projekt-Updates auch SQL-Scripte mit, die die Schema-Änderungen vornehmen - ohne Datenverlust.
Der Kunde macht aber eventuell Backups mit pg_dump und würde im hofft, daß er diese im Ernstfall auch wieder einspielen kann.
Sicher könnte man sagen, die Namen der Indizes sind egal, aber spätere Schemaänderungen könnten ja auch mal einen INDEX droppen wollen, der dann möglicherwiese wieder seinen alten Namen hat, wenn es zwischenzeitlich ein Dump/Restore gab. Und das ist definitiv nicht schön.
Hi,
okay, bekanntes Problem:
http://archives.postgresql.org//pgsql-bugs/2005-10/msg00337.php
Andreas
A. Kretschmer andreas.kretschmer@schollglas.com (Do 19 Mär 2009 12:57:25 CET):
Hi,
okay, bekanntes Problem: http://archives.postgresql.org//pgsql-bugs/2005-10/msg00337.php
Hm. Danke. Nicht schön. Aber nicht zu ändern. SLES 10-1...
Hallo,
Am Donnerstag, 19. März 2009 schrieb Heiko Schlittermann:
A. Kretschmer andreas.kretschmer@schollglas.com (Do 19 Mär 2009 12:57:25
CET):
okay, bekanntes Problem: http://archives.postgresql.org//pgsql-bugs/2005-10/msg00337.php
Hm. Danke. Nicht schön. Aber nicht zu ändern. SLES 10-1...
Sind das nicht genau die Fälle, für die man bei SLES (und vergleichbaren Distributionen) viel Geld auf den Tisch legt? Wenn ein Fehler auftritt -- zumal wenn er schon bekannt und auch gefixt ist -- wird der für die ausgelieferte Softwareversion behoben und innerhalb einer festgelegten Reaktionszeit eine gefixte und getestete Version ausgeliefert. Oder habe ich da was falsch verstanden?
Gruß Uwe
In response to Uwe Koloska :
Hallo,
Am Donnerstag, 19. März 2009 schrieb Heiko Schlittermann:
A. Kretschmer andreas.kretschmer@schollglas.com (Do 19 Mär 2009 12:57:25
CET):
okay, bekanntes Problem: http://archives.postgresql.org//pgsql-bugs/2005-10/msg00337.php
Hm. Danke. Nicht schön. Aber nicht zu ändern. SLES 10-1...
Sind das nicht genau die Fälle, für die man bei SLES (und vergleichbaren Distributionen) viel Geld auf den Tisch legt? Wenn ein Fehler auftritt -- zumal wenn er schon bekannt und auch gefixt ist -- wird der für die ausgelieferte Softwareversion behoben und innerhalb einer festgelegten Reaktionszeit eine gefixte und getestete Version ausgeliefert. Oder habe ich da was falsch verstanden?
Möglicherweise.
Es ist gefixt bzw. besser gelöst in 8.3, nicht aber in 8.1. Eine bestehende Anwendung von 8.1 auf 8.3 zu heben hätte natürlich Voteile wie z.B. bessere Performance. Aber auch Risiken, z.B. durch den Wegfall von automatischen Casts. Nicht wenige sind beim Umstieg auf 8.3 deswegen unsanft auf die Nase gefallen.
Heikos Problem ist nicht wirklich ein Bug (okay, da kann man sich trefflich streiten).
Also, ich weiß nicht, was bei SLES den Kunden versprochen wird, aber zaubern können die da wohl sicher auch nicht und somit keine Features aus der Zukunft in eine alte Version einbauen.
Andreas
Hallo,
Am Freitag, 20. März 2009 schrieb Andreas Kretschmer:
Also, ich weiß nicht, was bei SLES den Kunden versprochen wird, aber zaubern können die da wohl sicher auch nicht und somit keine Features aus der Zukunft in eine alte Version einbauen.
Genau darum aber geht es doch bei solchen langfristig angelegten Distributionen: Die Version bleibt gleich, um die Schnittstelle nicht zu verändern, aber Bugs werden gefixt und dafür unter Umständen zurückportiert.
Ich sehe gerade, dass Debian Etch auch noch PG 8.1.15 hat. Tritt dort der Fehler auch auf oder gibt es vielleicht schon einen Backport des Fixes?
Gruß Uwe
In response to Uwe Koloska :
Hallo,
Am Freitag, 20. März 2009 schrieb Andreas Kretschmer:
Also, ich weiß nicht, was bei SLES den Kunden versprochen wird, aber zaubern können die da wohl sicher auch nicht und somit keine Features aus der Zukunft in eine alte Version einbauen.
Genau darum aber geht es doch bei solchen langfristig angelegten Distributionen: Die Version bleibt gleich, um die Schnittstelle nicht zu verändern, aber Bugs werden gefixt und dafür unter Umständen zurückportiert.
Ich sehe gerade, dass Debian Etch auch noch PG 8.1.15 hat. Tritt dort der Fehler auch auf oder gibt es vielleicht schon einen Backport des Fixes?
Don't know. Wäre aber einen Versuch wert, allerdings ist es auch noch in 8.2.13, nicht mehr in 8.3.5. Ob es nach 8.1 schon gefunden hat weiß ich nicht.
Andreas
On Friday 20 March 2009, Uwe Koloska wrote:
Sind das nicht genau die Fälle, für die man bei SLES (und vergleichbaren Distributionen) viel Geld auf den Tisch legt? Wenn ein Fehler auftritt -- zumal wenn er schon bekannt und auch gefixt ist -- wird der für die ausgelieferte Softwareversion behoben und innerhalb einer festgelegten Reaktionszeit eine gefixte und getestete Version ausgeliefert. Oder habe ich da was falsch verstanden?
Fast richtig. Du bezahlst viel Geld für folgende Features:
a) Du kannst mit dem Finger auf jemanden zeigen, wenn ein Schuldiger gesucht wird
b) es werden Sicherheitsprobleme gelöst (nicht zu verwechseln mit Funktionalität)
c) es ist zertifiziert - sprich, wenn Du Enterprise-Applikation X drauf laufen läßt hat der Hersteller von X weniger Ausreden, wenn es nicht funktioniert und kann Dir nicht einfach den Support verweigern
Konrad
lug-dd@mailman.schlittermann.de