Hallo,
vorweg: ich habe so gut wie keine Ahnung von Datenbanken, bin blutiger
Anfänger. Jetzt habe ich mir von einem Entwickler sagen lassen, dass
Postgres (für die schreibt er Anwendungen) nicht von sich aus steuert,
wie mehrere Nutzer gleichzeitig mit der Datenbank arbeiten. Er sagte,
dass mehrere Nutzer zeitgleich denselben Datensatz bearbeiten können,
und wer zuletzt speichert (heißt das so?), dessen Daten sind dann in der
Datenbank, die des anderen Nutzers werden überschrieben.

Ist das so?
Mich hat das überrascht, da ich davon ausging, dass Postgres eine
gleichzeitige Änderung von sich aus nicht zulässt. Wie ich den
Entwickler verstanden habe, müsse die Anwendung, die mit der Datenbank
arbeitet, selbst dafür sorgen, dass die Zugriffe entsprechend
koordiniert und geschützt werden. Sorgt das nicht regelmäßig für
Durcheinander und Datenfehler? Schließlich müssen solche Situationen
erst einmal bemerkt werden, und die Bereinigung stelle ich mir auch
recht aufwendig vor.

Kann mich jemand erhellen?

--
Gruß
Alex

On Fri, 12 Apr 2024 07:55:02 Alexander Goetzenstein wrote:
> [...] Postgres (für die schreibt er Anwendungen) nicht von sich
> aus steuert, wie mehrere Nutzer gleichzeitig mit der Datenbank
> arbeiten. Er sagte, dass mehrere Nutzer zeitgleich denselben
> Datensatz bearbeiten können, und wer zuletzt speichert (heißt das
> so?), dessen Daten sind dann in der Datenbank, die des anderen
> Nutzers werden überschrieben.

> Ist das so?

Der Jurist würde sagen "das hängt davon ab", aber im Grund genommen
ist das bei vielen Szenarien so, ganz unabhängig von der Datenbank.

> Mich hat das überrascht, da ich davon ausging, dass Postgres eine
> gleichzeitige Änderung von sich aus nicht zulässt. Wie ich den
> Entwickler verstanden habe, müsse die Anwendung, die mit der
> Datenbank arbeitet, selbst dafür sorgen, dass die Zugriffe
> entsprechend koordiniert und geschützt werden.

Es fängt schon einmal mit der Frage an, wann eine Änderung
"gleichzeitig" ist. Anno damals, als Applikationen irgendwo auf
einem Rechner oder Host liefen und permanente Datenbankverbindungen
offen hatten, war die Aufgabenstellung eine ganz andere als heute,
wo eine Webanwendung (notgedrungen) für jeden Zugriff eine neue
Verbindung aufbaut. Du hast meist so etwas wie:

Benutzer A: zeigt Maske zum Bearbeiten von Datensatz A an
Benutzer B: zeigt Maske zum Bearbeiten von Datensatz A an
Benutzer B: speichert geänderten Datensatz A1 ab
Benutzer A: speichert geänderten Datensatz A2 ab

Was sollte die Datenbank hier tun? Sie weiss ja nicht, von welchem
Status Benutzer A beim Speichern ausgegangen ist. Verhindern könnte
das allenfall die Applikation.

> Sorgt das nicht regelmäßig für Durcheinander und Datenfehler?

An sich nicht, nein, denn die allermeisten Daten werden nicht
gleichzeitig von unterschiedlichen Leuten unterschiedlich bearbeitet
(oder es ist irrelevant, weil z.B. von zwei verschiedenen Edits von
Adress-Stammdaten die Datenbank ohnehin nicht sagen kann, welcher
davon korrekt ist, daher ebenso gut der zweite den ersten
überschreiben kann). Letztlich ist das aber genau die Frage, die
sich der Applikationsentwickler stellen und sorgfältig beantworten
muss und auch, wie er das - falls erforderlich - verhindern möchte.

Innerhalb eines Zugriffs (d.h. einer Zeile im obigen Beispiel) muss
jedoch Transaktionssicherheit herrschen, wenn Chaos verhindert
werden soll; man möchte z.B. darauf vertrauen können, dass das
Ergebnis eines SELECT auch beim nachfolgenden INSERT noch gültig
ist. Dafür gibt es (nicht nur in PostgreSQL) Vorkehrungen, die Du
z.B. hier nachlesen kannst:

<https://www.postgresql.org/docs/current/transaction-iso.html>

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Werben mit Stefan - traumhaft werden mit Ironie.
(Sloganizer)

Alexander Goetzenstein <alexander_goetzenstein@web.de> schrieb oder zitierte:
>Anfänger. Jetzt habe ich mir von einem Entwickler sagen lassen, dass
>Postgres (für die schreibt er Anwendungen) nicht von sich aus steuert,
>wie mehrere Nutzer gleichzeitig mit der Datenbank arbeiten. Er sagte,
>dass mehrere Nutzer zeitgleich denselben Datensatz bearbeiten können,
>und wer zuletzt speichert (heißt das so?), dessen Daten sind dann in der
>Datenbank, die des anderen Nutzers werden überschrieben.

PostgreSQL unterstützt ACID-Transaktionen, was die übliche
beste Praxis auf diesem Gebiet ist. Es kann sein, daß
bei einer bestimmten Datenbank bestimmte Teile davon aus
Effizienzgründen deaktiviert wurden oder eine Anwendung nicht
von allen Möglichkeiten solcher Transaktionen Gebrauch macht.

PostgreSQL unterstützt sowohl RS- als auch RX-Sperren auf einer
Zeile, die verhindern, daß andere Transaktionen diese Zeile
verändern beziehungsweise sogar sie lesen können.

Hallo,

Am 12.04.24 um 13:48 schrieb Stefan Froehlich:
> On Fri, 12 Apr 2024 07:55:02 Alexander Goetzenstein wrote:
>> [...] Postgres (für die schreibt er Anwendungen) nicht von sich
>> aus steuert, wie mehrere Nutzer gleichzeitig mit der Datenbank
>> arbeiten. Er sagte, dass mehrere Nutzer zeitgleich denselben
>> Datensatz bearbeiten können, und wer zuletzt speichert (heißt das
>> so?), dessen Daten sind dann in der Datenbank, die des anderen
>> Nutzers werden überschrieben.
>
>> Ist das so?
>
> Der Jurist würde sagen "das hängt davon ab", aber im Grund genommen
> ist das bei vielen Szenarien so, ganz unabhängig von der Datenbank.
>
>> Mich hat das überrascht, da ich davon ausging, dass Postgres eine
>> gleichzeitige Änderung von sich aus nicht zulässt. Wie ich den
>> Entwickler verstanden habe, müsse die Anwendung, die mit der
>> Datenbank arbeitet, selbst dafür sorgen, dass die Zugriffe
>> entsprechend koordiniert und geschützt werden.
>
> Es fängt schon einmal mit der Frage an, wann eine Änderung
> "gleichzeitig" ist. Anno damals, als Applikationen irgendwo auf
> einem Rechner oder Host liefen und permanente Datenbankverbindungen
> offen hatten, war die Aufgabenstellung eine ganz andere als heute,
> wo eine Webanwendung (notgedrungen) für jeden Zugriff eine neue
> Verbindung aufbaut. Du hast meist so etwas wie:
>
> Benutzer A: zeigt Maske zum Bearbeiten von Datensatz A an
> Benutzer B: zeigt Maske zum Bearbeiten von Datensatz A an
> Benutzer B: speichert geänderten Datensatz A1 ab
> Benutzer A: speichert geänderten Datensatz A2 ab
>
> Was sollte die Datenbank hier tun? Sie weiss ja nicht, von welchem
> Status Benutzer A beim Speichern ausgegangen ist. Verhindern könnte
> das allenfall die Applikation.

ich könnte mir vorstellen, dass die DB einen zum Schreiben geöffneten
Datensatz für andere Bearbeitungen sperrt und nur readonly-Zugriffe
zulässt, bis der Datensatz wieder geschlossen wird. So ähnlich, wie es
bspw. gängige Office-Anwendungen mit einer lock-Datei machen, nur eben
über interne Mechanismen. Im Grunde hätte ich so etwas als Standard
erwartet.

>> Sorgt das nicht regelmäßig für Durcheinander und Datenfehler?
>
> An sich nicht, nein, denn die allermeisten Daten werden nicht
> gleichzeitig von unterschiedlichen Leuten unterschiedlich bearbeitet
> (oder es ist irrelevant, weil z.B. von zwei verschiedenen Edits von
> Adress-Stammdaten die Datenbank ohnehin nicht sagen kann, welcher
> davon korrekt ist, daher ebenso gut der zweite den ersten
> überschreiben kann). Letztlich ist das aber genau die Frage, die
> sich der Applikationsentwickler stellen und sorgfältig beantworten
> muss und auch, wie er das - falls erforderlich - verhindern möchte.
>
>
> Innerhalb eines Zugriffs (d.h. einer Zeile im obigen Beispiel) muss
> jedoch Transaktionssicherheit herrschen, wenn Chaos verhindert
> werden soll; man möchte z.B. darauf vertrauen können, dass das
> Ergebnis eines SELECT auch beim nachfolgenden INSERT noch gültig
> ist. Dafür gibt es (nicht nur in PostgreSQL) Vorkehrungen, die Du
> z.B. hier nachlesen kannst:
>
> <https://www.postgresql.org/docs/current/transaction-iso.html>

Das schaue ich mir gleich mal an und hoffe, dass ich das auch
verstehe... ;-)

>
> Servus,
> Stefan
>

--
Gruß
Alex

Hallo,

Am 12.04.24 um 20:56 schrieb Stefan Ram:
> Alexander Goetzenstein <alexander_goetzenstein@web.de> schrieb oder
> zitierte:
>> Anfänger. Jetzt habe ich mir von einem Entwickler sagen lassen,
>> dass Postgres (für die schreibt er Anwendungen) nicht von sich aus
>> steuert, wie mehrere Nutzer gleichzeitig mit der Datenbank
>> arbeiten. Er sagte, dass mehrere Nutzer zeitgleich denselben
>> Datensatz bearbeiten können, und wer zuletzt speichert (heißt das
>> so?), dessen Daten sind dann in der Datenbank, die des anderen
>> Nutzers werden überschrieben.
>
> PostgreSQL unterstützt ACID-Transaktionen, was die übliche beste
> Praxis auf diesem Gebiet ist. Es kann sein, daß bei einer bestimmten
> Datenbank bestimmte Teile davon aus Effizienzgründen deaktiviert
> wurden oder eine Anwendung nicht von allen Möglichkeiten solcher
> Transaktionen Gebrauch macht.

zu diesem Stichwort habe ich diese Erklärung gefunden:

>> Sperren verhindern gleichzeitige Änderung von Datensätzen durch
>> mehrere Benutzer und die Rückgabe inkonsistenter Daten. Hierfür
>> werden z.B. gemeinsame, exklusive, beabsichtigte und andere Sperren
>> auf der Ebene von Datenbanken, Tabellen, Speicher-Seiten und Zeilen
>> verwendet.

ACID bezieht sich dabei auf die einzelne Transaktion, nicht auf die
gesamte DB, wenn ich es richtig verstanden habe.

Das dürfte ziemlich genau das sein, was ich erwartet hätte, was der
Entwickler, mit dem ich sprach, aber in Abrede stellte.

> PostgreSQL unterstützt sowohl RS- als auch RX-Sperren auf einer
> Zeile, die verhindern, daß andere Transaktionen diese Zeile
> verändern beziehungsweise sogar sie lesen können.

Was muss man tun, damit PostgreSQL diese Sperren anwendet?

--
Gruß
Alex

On Sat, 13 Apr 2024 10:25:51 Alexander Goetzenstein wrote:
> Am 12.04.24 um 13:48 schrieb Stefan Froehlich:
>> Anno damals, als Applikationen irgendwo auf einem Rechner oder
>> Host liefen und permanente Datenbankverbindungen offen hatten,
>> war die Aufgabenstellung eine ganz andere als heute, wo eine
>> Webanwendung (notgedrungen) für jeden Zugriff eine neue
>> Verbindung aufbaut. Du hast meist so etwas wie:

>> Benutzer A: zeigt Maske zum Bearbeiten von Datensatz A an
>> Benutzer B: zeigt Maske zum Bearbeiten von Datensatz A an
>> Benutzer B: speichert geänderten Datensatz A1 ab
>> Benutzer A: speichert geänderten Datensatz A2 ab

>> Was sollte die Datenbank hier tun? Sie weiss ja nicht, von welchem
>> Status Benutzer A beim Speichern ausgegangen ist. Verhindern könnte
>> das allenfall die Applikation.

> ich könnte mir vorstellen, dass die DB einen zum Schreiben
> geöffneten Datensatz für andere Bearbeitungen sperrt und nur
> readonly-Zugriffe zulässt, bis der Datensatz wieder geschlossen
> wird. So ähnlich, wie es bspw. gängige Office-Anwendungen mit
> einer lock-Datei machen, nur eben über interne Mechanismen. Im
> Grunde hätte ich so etwas als Standard erwartet.

Klar, wenn man das tut (PostgreSQL und die meisten anderen
Datenbanken können entsprechend betrieben werden), funktioniert
alles genau so, wie Du Dir das erwartest. Wenn Du das in der
maximalen Ausbaustufe durchziehst, gibt dabei allerdings zwei
Probleme:

1) ein Datensatz ist vom ersten SELECT bis zum abschließenden COMMIT
für andere (wenigstens zum Bearbeiten) gesperrt. Das kann dauern und
senkt die Benutzerzufriedenheit - was, wenn der erste Benutzer nach
dem Aufruf der Bildschirmmaske ins Wochenende gegangen ist?

2) die meisten aktuellen Anwendungen laufen irgendwo im Browser,
d.h. Du hast gar keine Sitzung, die "Anzeigen" und "Speichern"
einschließt, sondern zwei vollkommen getrennte Requests. In diesem
Fall, und der ist häufig, hat die Datenbank gar keine Möglichkeit,
die schwebende Transaktion als solche zu erkennen.

>> <https://www.postgresql.org/docs/current/transaction-iso.html>

> Das schaue ich mir gleich mal an und hoffe, dass ich das auch
> verstehe... ;-)

Das zu verstehen ist durchaus wichtig, denn selbst im zweiten Fall
möchte man doch innerhalb eines Schreibvorgangs garantierte
Konsistenz.

Dem Benutzer allenfalls auszugeben, dass das, was er gerade
bearbeitet hat, in der Zwischenzeit von jemand anderem gelöscht
wurde: Damit muss er leben, und bei etwas entspannterer Betrachtung
ist das auch gar kein Verlust (der andere hätte den Datensatz ja
auch ein paar Sekunden später löschen können, mit dem gleichen
Ergebnis). *Innerhalb* eines Schreibvorgangs (bestehend aus vielen
SQL-Statements) darf dergleichen jedoch nicht passieren.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Ein netter Gedanke - Stefan: jammern, welch perverses Verlangen!
(Sloganizer)

Alexander Goetzenstein <alexander_goetzenstein@web.de> wrote:

>>> [...] Postgres (für die schreibt er Anwendungen) nicht von sich
>>> aus steuert, wie mehrere Nutzer gleichzeitig mit der Datenbank
>>> arbeiten. Er sagte, dass mehrere Nutzer zeitgleich denselben
>>> Datensatz bearbeiten können, und wer zuletzt speichert (heißt das
>>> so?), dessen Daten sind dann in der Datenbank, die des anderen
>>> Nutzers werden überschrieben.

>>> Ist das so?

>> Der Jurist würde sagen "das hängt davon ab", aber im Grund genommen
>> ist das bei vielen Szenarien so, ganz unabhängig von der Datenbank.

>>> Mich hat das überrascht, da ich davon ausging, dass Postgres eine
>>> gleichzeitige Änderung von sich aus nicht zulässt. Wie ich den
>>> Entwickler verstanden habe, müsse die Anwendung, die mit der
>>> Datenbank arbeitet, selbst dafür sorgen, dass die Zugriffe
>>> entsprechend koordiniert und geschützt werden.

>> Es fängt schon einmal mit der Frage an, wann eine Änderung
>> "gleichzeitig" ist. Anno damals, als Applikationen irgendwo auf
>> einem Rechner oder Host liefen und permanente Datenbankverbindungen
>> offen hatten, war die Aufgabenstellung eine ganz andere als heute,
>> wo eine Webanwendung (notgedrungen) für jeden Zugriff eine neue
>> Verbindung aufbaut. Du hast meist so etwas wie:

>> Benutzer A: zeigt Maske zum Bearbeiten von Datensatz A an
>> Benutzer B: zeigt Maske zum Bearbeiten von Datensatz A an
>> Benutzer B: speichert geänderten Datensatz A1 ab
>> Benutzer A: speichert geänderten Datensatz A2 ab

>> Was sollte die Datenbank hier tun? Sie weiss ja nicht, von welchem
>> Status Benutzer A beim Speichern ausgegangen ist. Verhindern könnte
>> das allenfall die Applikation.

> ich könnte mir vorstellen, dass die DB einen zum Schreiben geöffneten
> Datensatz für andere Bearbeitungen sperrt und nur readonly-Zugriffe
> zulässt, bis der Datensatz wieder geschlossen wird. So ähnlich, wie es
> bspw. gängige Office-Anwendungen mit einer lock-Datei machen, nur eben
> über interne Mechanismen. Im Grunde hätte ich so etwas als Standard
> erwartet.

> […]

Das funktioniert aber auf so niedriger Ebene schlecht in
Mehrbenutzerumgebungen, und deshalb geht auch bei Office-An-
wendungen die Tendenz dahin, dass man mit mehreren Benutzern
gleichzeitig dieselbe Datei bearbeiten kann und Konflikte
anders signalisiert werden.

Wie in diesem Thread schon geschrieben: Man löst das Problem
normalerweise auf der Anwendungsebene, indem man man dem Be-
nutzer anzeigt, dass gerade ein anderer Benutzer auch diese
und jene Daten bearbeitet/bearbeiten will oder dass die Da-
ten zwischen den Klicks auf „Bearbeiten“ und „Speichern“
durch andere Benutzer geändert wurden, und fragt, ob die Än-
derungen überschrieben werden sollen, man sie überarbeiten
möchte, abbrechen will, etc.

Tim

Alexander Goetzenstein <alexander_goetzenstein@web.de> schrieb oder zitierte:
>Was muss man tun, damit PostgreSQL diese Sperren anwendet?

In bestimmten Fällen werden diese von PostgreSQL schon automatisch
angewendet, wenn sie erkennbar sinnvoll sind.

Siehe Abschnitt "13.3.2. Row-Level Locks" in dem PostgreSQL-Handbuch
"PostgreSQL 16.2 Documentation" von 2024.

Demnach können Sperren mit Klauseln wie "FOR UPDATE", "FOR
NO KEY UPDATE", "FOR SHARE", "FOR KEY SHARE" auch explizit
angewendet werden (wohl innerhalb einer Transaktion).

(Man sollte dazu aber auch vorher mit "SET TRANSACTION" die
gewünschte Isolationsstufe eingestellt haben. Das Verhalten
kann auch mit der "ON CONFLICT"-Klausel modifiziert werden.)

Allerdings kann damit wohl nicht das /Lesen/ einer Zeile verhindert
werden. Ich hatte zuvor geschrieben, daß es verhindert werden könne,
"daß andere Transaktionen diese Zeile verändern beziehungsweise
sogar sie lesen können", weil ich dies woanders gelesen hatte.
Aber jetzt kann ich nicht herausfinden, wie das genau gehen soll.
Allerdings kann man wohl mit einer ACCESS-EXCLUSIVE-Sperre einer
Table das Lesen in einer anderen Transaktion verhindern.

Möglicherweise können auch ADVISORY-Sperren (13.3.5. Advisory
Locks) verwendet werden, um in einer Anwendungen parallele
Bearbeitungen zu verhindern.

On Sat, 13 Apr 2024 13:36:31 Stefan Ram wrote:
> Demnach können Sperren mit Klauseln wie "FOR UPDATE", "FOR
> NO KEY UPDATE", "FOR SHARE", "FOR KEY SHARE" auch explizit
> angewendet werden (wohl innerhalb einer Transaktion).

Das ist halt ziemlich grausam, weil sehr fehleranfällig.

> Allerdings kann damit wohl nicht das /Lesen/ einer Zeile
> verhindert werden. Ich hatte zuvor geschrieben, daß es
> verhindert werden könne, "daß andere Transaktionen diese Zeile
> verändern beziehungsweise sogar sie lesen können", weil ich dies
> woanders gelesen hatte. Aber jetzt kann ich nicht herausfinden,
> wie das genau gehen soll.

Ich würde Isolation Leven serializable vorschlagen, damit wird alles
verhindert, was böse sein könnte (sofern alles brav in Transactions
durchgeführt wird, auch reine Lesezugriffe, und deren Gültigkeit
erst nach dem COMMIT als gegeben betrachtet wird).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, so superb wie die Erde.
(Sloganizer)