Einschränkung definiert DEFERRABLE INITIALLY IMMEDIATE ist immer noch ZURÜCKGESTELLT?

In Verbindung mit die Antwort stieß ich auf ein Phänomen, das ich nicht erklären kann.

Version:
PostgreSQL 9.1.2 auf x86_64-unknown-linux-gnu, compiled by gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit -

Betrachten Sie die folgende demo. Testbed:

CREATE TEMP TABLE t (
  id  integer
 ,txt text
 ,CONSTRAINT t_pkey PRIMARY KEY (id) DEFERRABLE INITIALLY IMMEDIATE
);

INSERT INTO t VALUES
 (1, 'one')
,(2, 'two');

1) UPDATE-Anweisung geändert wird, die mehrere Zeilen:

UPDATE t
SET    id = t_old.id
FROM   t t_old
WHERE (t.id, t_old.id) IN ((1,2), (2,1));

Scheint es einen bug in der aktuellen Implementierung? Die oben genannten UPDATE funktioniert, obwohl es sollte nicht. Die Einschränkung definiert INITIALLY IMMEDIATE und ich habe nicht mit SET CONSTRAINTS.

Bin ich etwas fehlt, oder ist dies ein (eher harmloser) bug?

2) Daten ändern CTE

Folglich ein Daten ändern CTE funktioniert, auch wenn es fehlschlägt, mit einem NOT DEFERRED pk:

WITH x AS (
    UPDATE t SET id = 1 WHERE id = 2
    )
UPDATE t SET id = 2 WHERE id = 1;

Ich zitiere die Handbuch auf Allgemeine Tabellenausdrücke:

Den sub-Anweisungen in MIT ausgeführt werden, die gleichzeitig miteinander
und mit der Haupt-Abfrage. Deshalb, wenn Sie Daten ändern
Aussagen, die Reihenfolge, in der die angegebenen updates eigentlich
geschehen ist unberechenbar. Alle Anweisungen ausgeführt, die mit der gleichen
Schnappschuss (siehe Kapitel 13), so dass Sie nicht "sehen" gegenseitig Ihre Wirkung
auf dem Ziel-Tabellen.

3) Mehrere UPDATE-Anweisungen in einer Transaktion

Ohne SET CONSTRAINTS dieses schlägt mit einem EINMALIGEN Verstoß - wie erwartet:

BEGIN;
-- SET CONSTRAINTS t_pkey DEFERRED;
UPDATE t SET id = 2 WHERE txt = 'one';
UPDATE t SET id = 1 WHERE txt = 'two';
COMMIT;
Gleiche mit 9.1.3 unter Windows. Sie sollten berichten, dass ein Fehler der PostgreSQL-team.
Die Art, wie ich Lesen Sie die Dokumentation, ich denke, das update fehlschlagen sollte. Würde ich es nennen, ein Fehler.
Können Sie der Dokumentation, die zeigt, warum "Die da oben UPDATE funktioniert, obwohl es nicht sein sollte." - warum das update nicht funktionieren sollte?
Betrachten Sie die Antworten unten. Auch Folgen den link in die Kommentare und prüfen, Peter Eisentraut ist die Antwort da.
was sagt "Der SQL-standard sagt, dass die Eindeutigkeit erzwungen werden soll, die nur am Ende der Anweisung ... Zu erhalten standard-konform Verhalten, erklären die constraint als DEFERRABLE aber nicht die latenten (d.h., ZUNÄCHST IMMEDIATE)" - das ist genau das, was Sie tun, damit das update erfolgreich sein sollte, weil am Ende der Anweisung werden alle IDs sind einzigartig.

InformationsquelleAutor Erwin Brandstetter | 2012-04-05

  1. 28

    Ich erinnere mich, dass Sie hob einen fast identischen Punkt, wenn PG9 war im alpha-Zustand. Hier war die Antwort von Tom Lane (high-profile-PG-core-Entwickler):
    http://archives.postgresql.org/pgsql-general/2010-01/msg00221.php

    Kurz: wird nicht behoben.

    Nicht zu sagen, dass ich einverstanden mit Ihrem Vorschlag, dass das aktuelle Verhalten ist ein bug. Betrachten Sie es von der gegenüberliegenden Winkel: es ist das Verhalten von NOT DEFERRABLE das ist falsch.

    In der Tat, die constraint-Verletzung in diesem UPDATE sollte nie passieren, in jedem Fall, denn am Ende des UPDATES wird die Einschränkung zufrieden. Der Zustand am Ende des Befehls ist es, was zählt. Die Zwischenzustände, die während der Ausführung einer einzelnen Anweisung sollte nicht für den Benutzer verfügbar gemacht.

    Scheint es, wie die PostgreSQL implementiert die non-deferrable constraint-von der Dublettenprüfung nach jeder Zeile aktualisiert, und nicht, sofort auf das erste Duplikat, das ist im wesentlichen fehlerhaft. Aber dies ist ein bekanntes problem, das vermutlich so alt ist wie PostgreSQL.
    Heute ist die Abhilfe für dieses ist es gerade, verwenden Sie ein DEFERRABLE constraint. Und es gibt eine gewisse Ironie in sich, dass Sie suchen, Sie als mangelhaft, weil es nicht zu scheitern, während irgendwie soll es die Lösung sein, um den Ausfall in den ersten Platz!

    Zusammenfassung des status quo in PostgreSQL 9.1

    • NOT DEFERRABLE UNIQUE oder PRIMARY KEY constraints werden überprüft nach jeder Zeile.

    • DEFERRABLE constraints auf IMMEDIATE (INITIALLY IMMEDIATE oder über SET CONSTRAINTS) überprüft werden nach jeder Anweisung.

    • DEFERRABLE constraints auf DEFERRED (INITIALLY DEFERRED oder über SET CONSTRAINTS) überprüft werden nach jeder Transaktion.

    Beachten Sie die Besondere Behandlung von UNIQUE /PRIMARY KEY Einschränkungen.
    Zitat aus dem Handbuch Seite für CREATE TABLE:

    Einschränkung, dass nicht zurückstellbaren wird sofort geprüft werden, nach jedem Befehl.

    Während es Staaten, die weiter unten in der Kompatibilität Abschnitt unter Non-deferred uniqueness constraints:

    Wenn ein UNIQUE oder PRIMARY KEY Einschränkung nicht zurückstellbaren, PostgreSQL
    Prüfungen für die Eindeutigkeit sofort, wenn eine Zeile eingefügt oder
    geändert. Der SQL-standard sagt, dass die Eindeutigkeit erzwungen werden soll
    nur am Ende der Anweisung; das macht einen Unterschied, wenn, für
    Beispiel, einen einzigen Befehl updates, die mehrere Schlüssel-Werte. Zu erhalten
    standard-konform Verhalten, erklären die Einschränkung als DEFERRABLE aber
    nicht die latenten (d.h., INITIALLY IMMEDIATE). Beachten Sie, dass das sein kann
    deutlich langsamer als die sofortige Eindeutigkeit überprüfen.

    Fett-Hervorhebung von mir.

    Wenn Sie alle FOREIGN KEY Einschränkungen Verweis auf die Spalte(N), DEFERRABLE ist nicht eine option, weil (pro Dokumentation):

    Den referenzierten Spalten müssen die Spalten einer non-deferrable unique
    oder primary key-Einschränkung in der referenzierten Tabelle.

    Dies ist inzwischen geklärt, in einer post an [email protected].

    InformationsquelleAutor Daniel Vérité

  2. 4

    Es eine kleine Dokumentation, bug hier, aber nicht für den Fall, Sie sind zeigt. Wenn Sie eine Transaktion BEGINNEN und versuchen, die updates nacheinander, Sie scheitern, aber wenn ein einzigen Anweisung lässt die Dinge in einem guten Zustand, es nicht beschweren. Die docs sagen:

    Wenn ein constraint deferrable, diese Klausel gibt die Standard-Zeit
    um zu überprüfen, die Einschränkung. Wenn die Einschränkung ist ZUNÄCHST das UNMITTELBARE, es
    geprüft wird nach jeder Anweisung. Dies ist die Standardeinstellung. Wenn die
    Einschränkung ist ZUNÄCHST ZURÜCKGESTELLT, es wird nur überprüft, am Ende des
    die Transaktion.

    Das ist genau das, was passiert zu sein scheint. Was ist die überraschung für mich, da die Dokumentation der DEFERRABLE, die sagt in Teil:

    Einschränkung, dass nicht zurückstellbaren wird sofort geprüft werden, nachdem
    jeder Befehl.

    Ohne die DEFERRABLE INITIALLY IMMEDIATE Optionen, die beispielsweise update fehlschlägt, obwohl die UPDATE - Anweisung (vermutlich Konstituierung der "Befehl") lässt die Dinge in einem guten Zustand. Vielleicht sind die docs geändert werden sollte, um zu sagen, dass ein NOT DEFERRABLE Einschränkung erzwungen als jede Zeile wird geändert durch eine Erklärung?

    Mit etwas Verzögerung habe ich vorgeschlagen, eine Korrektur wie du vorgeschlagen [email protected].

    InformationsquelleAutor kgrittn

Schreibe einen Kommentar