Postgresql Objekt-ID und Tupeln

I manchmal Nachrichten wiePostgresql Objekt-ID und Tupeln

Prozess 12990 wartet ExclusiveLock auf Tupel (889,66) der Relation 17720 der Datenbank 17607 sehen; blockiert durch Prozess 12992.

So natürlich ist der 'Prozess' Teil ziemlich klar, aber ich weiß nicht, wie man zwischen der Relation ID und einem menschlich lesbaren Namen korreliert. Ich weiß auch nicht wirklich, was ich vom Tupelstück machen soll.

Wer weiß, wie man diese Nachrichten liest und nützliche Daten von ihnen liest?

Danke!

Quelle

2010-08-25 user431221

Sie können dies in den Systemtabellen nachschlagen: Die hier interessierende ist pg_class.

Doing eine Abfrage wie

SELECT OID, relname FROM pg_class 
oid |    relname    
-------+------------------------------------ 
    1247 | pg_type 
11550 | user_mapping_options 
11554 | user_mappings 
11494 | triggered_update_columns 
11497 | triggers

oder eher

SELECT relname FROM pg_class WHERE OID=17720

könnte Licht auf die Schleusen vergießen.

Quelle

2010-08-25 21:47:45

Danke! Ich habe die ID zum Relation Mapping herausgefunden, aber immer noch nicht sicher, was ich von den Tupeln machen soll ... – user431221

Eigentlich sollte ich klarstellen - nicht sicher, wie man die Tupel-Notation liest (x, y) und wie ich das verstehen kann Was hat den Deadlock verursacht? – user431221

OK, ein weiteres Bit Daten gefunden - die Nummern sind Transaktions-IDs, die das Tupel/die Zeile eingefügt oder gelöscht haben. Gibt es eine Möglichkeit, eine Vorstellung davon zu bekommen, welche SQL diese Transaktionen ausgeführt wurden? – user431221

Eine "Relation" ist eine Tabelle und ein "Tupel" ist eine Zeile.

Hier a nice shortcut für das Erhalten der Name der Tabelle, aus der Tabelle ID (Sie können auch die pg_class Tabelle abfragen):

=> select 17720::regclass; 
┌──────────┐ 
│ regclass │ 
├──────────┤ 
│ my_table │ 
└──────────┘ 
(1 row)

Nun, wie etwa die Reihe? Das "Tupel-Bit" ist ein tuple identifier, und jede Tabelle in Ihrer Datenbank hat eine spezielle system column namens ctid wo diese Kennungen gespeichert sind. Nun, da wir die Tabelle in Frage wissen, was wir tun können:

=> select * from my_table where ctid='(889,66)';

jedoch! Aus den Systemspaltedokumenten (Hervorhebung hinzugefügt): "Obwohl das ctid verwendet werden kann, um die Zeilenversion sehr schnell zu finden, wird das ctid einer Zeile ändern, wenn es aktualisiert oder um VACUUM FULL verschoben wird. Daher ist ctid nutzlos wie eine langfristige Zeilenkennung. " Mit anderen Worten, wenn Sie schnell genug sind, können Sie wahrscheinlich darauf vertrauen, dass die zurückgegebene Zeile diejenige ist, die am Deadlock beteiligt ist, aber diese Information wird nicht für immer verfügbar sein.

Quelle

2014-08-20 14:09:55 whit537

danke für diesen einen - nützlich und klar! – zeroDivisible

Postgresql Objekt-ID und Tupeln

Antwort

Verwandte Themen