Postgres-xl currval of sequence

Hallo,

ich habe Postgres-XL installiert und merke nun, das ich beim Einfügen eines Datums die ID nicht bekommen kann, der Fehler der auftritt lautet folgender maßen:
psycopg2.errors.ObjectNotInPrerequisiteState: currval of sequence “table_id_seq” is not yet defined in this session

Was mach ich nun?

P.S.: Ohne Cluster geht es natürlich.

nur zur Sicherheit: Du hast auch vorher ein INSERT gemacht?

Btw.: XL ist meines Wissens nach, nun ja, wird nicht weiter entwickelt …

Ich habe mit pg-xl noch nicht gearbeitet.

Wenn die Session nicht die gleiche ist, ist das eben so, erstmal. Sie ist genau dafür gemacht, in einer (der eigenen) aktuellen Session, den aktuellen Wert einer Sequence zu erhalten.

Die Frage wäre, in welchem Kontext dieses Problem auftritt, die Lösung wäre evtl. nicht mit einer Sequence zu arbeiten. Bei Postgres fällt mir zuallererst “RETURNING” ein.

Man kann auch die current values anderer Sessions abfragen, aber das ist m.E. ein Glücksspiel.

Also wie sieht Deine Code Sequence aus, die zu diesem Problem führt?

Genau! Insert und dann det currentval.

Was soll ich denn statt Postgres-XL verwenden? Ich brauche multi-master Replikation.

Ich rufe ein einfacen Insert Befehl aus und will die id(primary key) erhalten.

P.S.: Auf Glücksspiele stehe ich nicht gerade, heheheh

Ja returning war es!
Wie kann ich den ersten primary key zurück geben ohne den Namen zu wissen?
sagen wir mal in einer Tabelle ist der PK id
und in einer anderen Tabelle row,
gibt es ein Trick den Wer zurück zu geben ohne den Namen zu wissen?
Ich habe schon RETURNING 0 versucht, hat aber nicht funktioniert.

Den ersten? Primary Key nennt sich nicht deswegen so, weil es davon ganz viele gibt.
Es gibt Modelle, wo er über mehrere Spalten geht.
Ich kann Dir nicht ganz folgen. IdR weiß man, wie die Spalten heißen, die man befüllt.

Insert into <mytable> (<fieldlistWithoutPKID>)  values (<correspondingValuelist>) 
returning <IDColumn>[, <otherColumnsIfYouLike>];

Du wirst vielleicht irgendein Werkzeug haben oder eine Dokumentation, die die PK Spalte ermittelt oder darstellt?

BDR. XL ist tot. BDR ist wirklich cool;-)

Ich möchte eine allgemeingültige Anweisung verwenden.
In meinen Tabellen habe ich immer nur ein PK.

heheh, hätte ich das vorher gewusst hätte ich 2 Wochen Zeit sparen können.

Ist das dieses Projekt?

Letztes Update war vor 3 Jahren.

Radio Erewan: im Prinzip ja.

Nur daß 2ndQuadrant nun EDB ist (ich hab 2016 bei 2ndQ angefangen und bin nun bei EDB). BDR ist KEIN OPEN SOURCE, aber funktioniert wirklich gut, wir haben große Kunden z.B. im Finanzbereich, die das nutzen. Wenn Du eine Kreditkarte hast - dann gehen Deine Transaktionen sehr wahrscheinlich über ein BDR-System :wink:

Natürlich. Du kannst nicht mehr als einen PK pro Tabelle haben.

Wenn Du currval() verwenden willst, dann musst Du doch den Namen der Sequenz wissen die ja spezifisch für die Tabelle ist. Warum kennst Du dann nicht die Namen der PK Spalten?

Weil ich immer gerne allgemeingültige Anweisungen verwende.

Gute Idee, dann musst Du Dir Konventionen oder Verfahren überlegen, die das in Deiner Umgebung ermöglichen. Also Namenskonventionen, Hilfsfunktionen usw.
Gegenfragen:
Woher kennst Du die Namen der restlichen Felder, die Du sonst so in einem Statement benutzt?
Oder spezifischer: Wie nennst Du Deine FK Spalten auf die PK Spalten, deren Namen Du nicht kennst?

1 „Gefällt mir“

Hier mal noch aus unserem Portal (nur für Kunden sichtbar):

About BDR

Postgres-BDR (Bi-Directional Replication for PostgreSQL) brings ground-breaking distributed database capabilities to PostgreSQL. BDR as a multi-master replication extension for PostgreSQL databases has been in full production status since 2014. In the complex environment of replication, BDR achieves efficiency and accuracy, ensuring very high availability of all nodes in a geographically distributed cluster.

An overview of BDR, including its features and their benefits, use cases, and deployment options, is available publicly in the Postgres-BDR white paper.

BDR 4.0

BDR 4.0 is the current release supporting v12-14 of PostgreSQL, EDB Postgres Extended Server (formerly 2ndQuadrant Postgres), and EDB Postgres Advanced Server. Advanced BDR features are only available with Extended Server (for PostgreSQL compatibility) and Advanced Server (for Oracle compatibility). For more details, please see the feature compatibility appendix from the documentation link below.

The documentation for the current release is available here:

BDR 3.7

BDR 3.7 is the current stable release supporting v11-13 of PostgreSQL, EDB Postgres Extended Server (formerly 2ndQuadrant Postgres), and EDB Postgres Advanced Server. Certain advanced BDR features are only available with Extended Server and Advanced Server, and these can be found in the first section following the BDR compatibility matrix from the documentation link below. BDR version 3 is built on the pglogical3 extension and requires it to be installed in order to work.

The documentation for the current stable release (3.7 LTS) is available here:

BDR 3.6

BDR 3.6 is the prior stable release, which is available in two editions. The Standard Edition which works with PostgreSQL v10-11. And, the Enterprise Edition, which provides additional features that are useful in more advanced usage scenarios, requires 2ndQuadrant Postgres v11.

The documentation for the previous stable (3.6 LTS) release is available here:

Software and Support

Access to BDR packages is managed via the 2ndQuadrant Software Subscriptions system in the Support Portal. The repository names for different versions and Postgres variants are listed on each major version’s page.

Additional information about installing BDR is available in the BDR3 packages and documentation article.

Support for BDR is available via the Postgres-BDR add-on to the Standard and Enterprise subscription plans. For more information, visit the EDB subscription plans page on our website.

BDR is distributed under EDB License.

Ich nehme mal an, eine privat Person kann sich soetwas nicht leisten, stimmts?

ich kenne die Preise nicht, mach keinen Vertrieb (mehr). Ja, kostet schon etwas. Wenn Du magst, kann ich unseren Vertrieb auf Dich loslassen, brauch nur Deine Adresse …

Nein danke.
Weder habe ich Geld, noch werde ich das Produkt als ungeimpfter wohl nicht verwenden dürfen.

Naja, currval('table_id_seq') ist auch keine allgemeingültige Anweisung

Aus meiner Sicht, passen “Ich brauche multi-master Replikation” und “eine privat Person” irgendwie nicht zusammen. Warum braucht man als Privatperson eine multi-master Replikation? Welches Problem willst Du damit lösen? Es ist z.B. ein verbreiteter Irrtum, dass man damit den Schreibdurchsatz skalieren kann (eher im Gegenteil, weil ja alles n-mal geschrieben wird, anstatt nur einmal)

Vielleicht reicht ja eine Setup mit foreign data wrappers damit Du eine “verteilte” Datenbank bekommst.

1 „Gefällt mir“