deadlocks beim anmelden auch nach commit: 5609a646164465de4a4217a2757c27d4c0b6bcee

[information@…]

INSERT INTO auth.session_content (session_id, sess_key, sess_value) VALUES (?, ?, ?) (cbafc2c971d749fa85f717ed687da6d3, login, --- markus
)
ERROR: deadlock detected
DETAIL: Process 25129 waits for ShareLock? on transaction 965; blocked by process 25128.
Process 25128 waits for ShareLock? on transaction 966; blocked by process 25129.
HINT: See server log for query details.
CONTEXT: SQL statement "SELECT 1 FROM ONLY "auth"."session" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"

Nach Aktualisieren bzw. nach Aufruf einer neuen Seite verschwindet der Fehler ...

Betrifft auch wieder postgres 8.4 nach Anlegen eines neuen Mandanten.

Anbei der entsprechende Log von postgres

2011-01-19 15:42:42 CET ERROR: relation "schema_info" does not exist at character 17
2011-01-19 15:42:42 CET STATEMENT: SELECT tag FROM schema_info LIMIT 1
2011-01-19 15:42:43 CET ERROR: multiple primary keys for table "project" are not allowed
2011-01-19 15:42:43 CET STATEMENT: ALTER TABLE project ADD PRIMARY KEY (id);
2011-01-19 15:42:44 CET ERROR: schema "tax" does not exist
2011-01-19 15:42:44 CET STATEMENT: DROP SCHEMA tax CASCADE;
2011-01-19 15:43:11 CET ERROR: deadlock detected
2011-01-19 15:43:11 CET DETAIL: Process 25129 waits for ShareLock? on transaction 965; blocked by process 25128.

Process 25128 waits for ShareLock? on transaction 966; blocked by process 25129.
Process 25129: INSERT INTO auth.session_content (session_id, sess_key, sess_value) VALUES ($1, $2, $3)
Process 25128: DELETE FROM auth.session_content WHERE session_id = $1

2011-01-19 15:43:11 CET HINT: See server log for query details.
2011-01-19 15:43:11 CET CONTEXT: SQL statement "SELECT 1 FROM ONLY "auth"."session" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
2011-01-19 15:43:11 CET STATEMENT: INSERT INTO auth.session_content (session_id, sess_key, sess_value) VALUES ($1, $2, $3)
2011-01-19 15:45:56 CET ERROR: deadlock detected
2011-01-19 15:45:56 CET DETAIL: Process 25304 waits for ShareLock? on transaction 976; blocked by process 25303.

Mehr Infos, please. FCGI? Was heißt "nach Anlegen eines neuen Mandanten"? Welche Schritte hast du genau ausgeführt?

1.) kein fcgi

2.) admin.pl -> neue DB erstellen (SKR04) -> Benutzer DB zuordnen -> Benutzer in Gruppe Vollzugriff -> anmelden mit Benutzer -> DB-Upgradeskripte -> FEHLER

Kann ich in der aktuellen unstable mit PostgreSQL 8.4 nicht reproduzieren. Hier meine Schritte (nicht FCGI):

1. Admin-Bereich angemeldet
2. DB-Admin gedrückt
3. Login-Daten eingegeben, "Datenbank anlegen"
4. DB-Namen vergeben
5. "Anlegen"
6. Er legt an.
7. Benutzer umkonfiguriert.
8. login.pl aufgerufen
9. Mit Benutzer angemeldet. Es erscheint die Warnung, dass gleich aktualisiert wird. Weiter.
10. Es erscheint die Meldung vom Upgrade "Update SKR04: neues Steuerkonto 3804 (19%) für innergemeinschaftlichen Erwerb", dass nichts zu tun ist. Weiter.
11. Jetzt dauert es eine Weile. Danach werden alle Updates als eingespielt angezeigt. Weiter.
12. Menü erscheint.

Kein Deadlock.

Bist du sicher, dass du nicht gleichzeitig irgend etwas Anderes laufen hast, das eine Verbindung zur Auth-DB hat? Z.B. ein psql, die Lx-Office-Console oder eine noch laufende FCGI-Instanz.

Noch was. Hast du die Auth-DB in derselben DB, wie die, die du gerade für SKR04 angelegt hast?

(In reply to comment #3)

Kann ich in der aktuellen unstable mit PostgreSQL 8.4 nicht reproduzieren. Hier
meine Schritte (nicht FCGI):

1. Admin-Bereich angemeldet
2. DB-Admin gedrückt
3. Login-Daten eingegeben, "Datenbank anlegen"
4. DB-Namen vergeben
5. "Anlegen"
6. Er legt an.
7. Benutzer umkonfiguriert.
8. login.pl aufgerufen
9. Mit Benutzer angemeldet. Es erscheint die Warnung, dass gleich aktualisiert

wird. Weiter.

10. Es erscheint die Meldung vom Upgrade "Update SKR04: neues Steuerkonto 3804

(19%) für innergemeinschaftlichen Erwerb", dass nichts zu tun ist. Weiter.

11. Jetzt dauert es eine Weile. Danach werden alle Updates als eingespielt

angezeigt. Weiter.

12. Menü erscheint.

Kein Deadlock.

Bist du sicher, dass du nicht gleichzeitig irgend etwas Anderes laufen hast,
das eine Verbindung zur Auth-DB hat? Z.B. ein psql, die Lx-Office-Console oder
eine noch laufende FCGI-Instanz.

Noch was. Hast du die Auth-DB in derselben DB, wie die, die du gerade für SKR04
angelegt hast?

Ich habe das Problem auch ab und zu, wenn ich mich einmal ab- und wieder anmelde geht es aber normal weiter. Ich konnte noch keine Systematik dahinter feststellen, es ist bei mir aber nicht beim Neuanlegen eines Mandanten. Was ich häufiger mache ist den Testmandanten mit den Daten aus dem Echtmandanten zu syncen, da könnte das schon eher sein. Direkt, nachdem der Fehler aufgetaucht ist, habe ich mal ausgeführt:

select * from pg_stat_activity where datname='deutschlandtest';

datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port

---

18186656 | deutschlandtest | 13878 | 10 | postgres | select * from pg_stat_activity where datname='deutschlandtest'; | f | 2011-01-20 11:48:53.343528+01 | 2011-01-20 11:48:53.343528+01 | 2011-01-20 11:48:11.568002+01 | ::1 | 35285

(1 row)

Sonst ist da nichts.

Hi,
da wir gerade viele neue Server bauen ;-) anbei nochmal die Bestätigung von gestern:

Ein select * from pg_stat_activity, gibt auch nur einen Prozess:

11564 | postgres | 18085 | 10 | postgres | |

Noch was. Hast du die Auth-DB in derselben DB, wie die, die du gerade für SKR04 angelegt hast?

Hmm. Keine Ahnung, hilft diese Ausgabe:

template1=# select datname from pg_database;

datname

---

template1
template0
postgres
lxerp_auth
TEST

Ich kriege den Fehler regelmässig beim Einloggen wenn ich Benutzer wechsel, die auf unterschiedliche Datenbanken zugreifen. Unter fcgi, allerdings noch dem alten fcgi, ist es sogar so, daß bei Wechsel eines Benutzers die Datenbank nicht mit gewechselt wird, und der neue Benutzer auf einmal die Daten des alten Benutzers sieht.

ich teste

nope. immernoch nicht nachstellbar.

sowohl mit 8.3/8.4, mit/ohne fcgi, mit remote db/lokal, mit content db in der auth db und ohne. nichts.

Ich fürchte Ihr müsst uns das Freitag mal live zeigen.

Deadlock wirklich

Wie gesagt, wir haben das derzeit in 2 Kundenprojekte und würden auch locker eine Stunde dafür zahlen (so sehr nervt uns das).

Das ist schön, dass ihr alle Geld dafür zahlen würdet, aber ich kann das Problem immer noch nicht reproduzieren.

Wie gesagt, ssh-Zugang auf einem Testsystem geben wir dir auch gerne ... Ansonsten warten wir einfach ab.

Ich kann es nun reproduzieren, und mit etwas Einsatz von 'curl' kann ich es sogar ziemlich schnell forcieren. Es tritt bei FCGI nahezu sofort auf, wenn ich gleichzeitig drei curl-Prozesse auf Schleife laufen habe. Es tritt mit CGI ebenfalls auf, dort aber viel seltener -- klar, wenn Prozesse unterschiedlich lange zum Startup brauchen, dann ist das Zeitfenster für den Deadlock kleiner.

Ich habe noch keine Idee, wie ich es beheben kann.

Sollte in Revision 0c32dd23 behoben sein.