http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Guardiamo. \u00c8 evidenziato in rosso il numero della transazione. Qui \u00e8 mostrata la funzione SELECT pg_back. Restituisce la mia transazione e l'ID di questa transazione. <\/p>\n
<\/p>\n
Un altro punto, se ti piace questa presentazione e vuoi lanciarla nel tuo database, puoi seguire questo link evidenziato in rosa e scaricare l'SQL per questa presentazione. E puoi semplicemente eseguirla nel tuo PSQL e l'intera presentazione apparir\u00e0 sul tuo schermo immediatamente. Non conterr\u00e0 colori, ma almeno potremo vederla.<\/p>\n
<\/p>\n
<\/p>\n
In questo caso vediamo l'ID della transazione. Questo \u00e8 il numero che le abbiamo assegnato. E c'\u00e8 anche un altro tipo di ID transazione in Postgres, chiamato ID transazione virtuale.<\/p>\n
<\/p>\n
E dobbiamo capire questo. \u00c8 molto importante, altrimenti non saremo in grado di comprendere il blocco in Postgres.<\/p>\n
<\/p>\n
L'ID transazione virtuale \u00e8 un ID della transazione che non contiene valori permanenti. Ad esempio, se eseguo un comando SELECT, probabilmente non cambier\u00f2 il database, non bloccher\u00f2 nulla. Quindi, quando eseguiamo un semplice SELECT, non diamo a questa transazione un ID permanente. Le diamo solo un ID virtuale.<\/p>\n
<\/p>\n
E questo aumenta le prestazioni di Postgres, migliorando le capacit\u00e0 di pulizia, quindi l'ID delle transazioni virtuali \u00e8 composto da due numeri. Il primo numero prima della barra \u00e8 l'ID del backend. E a destra vediamo solo un contatore.<\/p>\n
<\/p>\n
<\/p>\n
Quindi se eseguo una query, dice che l'ID del backend \u00e8 2. <\/p>\n
<\/p>\n
<\/p>\n
E se eseguo una serie di tali transazioni, vediamo che il contatore aumenta ogni volta che eseguo una query. Ad esempio, quando eseguo una query 2\/10, 2\/11, 2\/12, ecc. <\/p>\n
<\/p>\n
<\/p>\n
Si prega di notare che qui ci sono due colonne. A sinistra vediamo l'ID virtuale della transazione \u2013 2\/12. E a destra abbiamo l'ID permanente della transazione. E questo campo \u00e8 vuoto. E questa transazione non modifica il database. Quindi non le assegno un ID permanente.<\/p>\n
<\/p>\n
<\/p>\n
Non appena eseguo il comando ANALYZE, la stessa query mi restituisce un ID permanente per la transazione. Guarda come \u00e8 cambiato. Prima non avevo questo ID, ora \u00e8 apparso.<\/p>\n
<\/p>\n
<\/p>\n
Quindi, qui c'\u00e8 un'altra query, un'altra transazione. Il numero di transazione virtuale \u00e8 2\/13. E se richiedo l'ID permanente della transazione, quando eseguo la query, lo ottengo. <\/p>\n
<\/p>\n
<\/p>\n
Quindi, ancora una volta. Abbiamo un ID virtuale della transazione e un ID permanente della transazione. Comprendi semplicemente questo punto per capire il comportamento di Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Passiamo alla terza sezione. Qui attraverseremo semplicemente i vari tipi di blocchi in Postgres. Non \u00e8 molto interessante. L'ultima sezione sar\u00e0 molto pi\u00f9 interessante. Ma dobbiamo esaminare le basi, altrimenti non capiremo ci\u00f2 che seguir\u00e0. <\/p>\n
<\/p>\n
Esamineremo questa sezione, guarderemo ogni tipo di blocco. E vi mostrer\u00f2 esempi di come vengono impostati, come funzionano, e vi mostrer\u00f2 alcune query che possono essere utilizzate per vedere come funziona il blocco in Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Per creare una query e vedere cosa sta succedendo in Postgres, dobbiamo eseguire una query in un sistema di visualizzazione. In questo caso, in rosso, abbiamo pg_lock. Pg_lock \u00e8 una tabella di sistema che ci dice quali blocchi sono attualmente in uso in Postgres.<\/p>\n
<\/p>\n
Tuttavia, \u00e8 molto difficile per me mostrarti pg_lock da solo, perch\u00e9 \u00e8 piuttosto complesso. Quindi ho creato una vista che mostra pg_locks. E fa anche un po' di lavoro per me che mi aiuta a capire meglio. Cio\u00e8, esclude i miei blocchi, la mia sessione, ecc. \u00c8 semplicemente una SQL standard e permette di mostrarvi meglio cosa sta succedendo. <\/p>\n
<\/p>\n
<\/p>\n
Un altro problema \u00e8 che questa vista \u00e8 molto ampia, quindi devo creare una seconda vista: lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Quindi, abbiamo creato una tabella chiamata Lockdemo. E abbiamo creato una riga l\u00ec. Questa \u00e8 la nostra tabella di esempio. Creeremo delle sezioni per mostrarvi semplicemente degli esempi di blocchi. <\/p>\n
<\/p>\n
<\/p>\n
Quindi, una riga, una colonna. Il primo tipo di blocco si chiama ACCESS SHARE. \u00c8 il blocco meno restrittivo. Questo significa che praticamente non entra in conflitto con gli altri blocchi.<\/p>\n
<\/p>\n
E se vogliamo definire esplicitamente il blocco, eseguiamo il comando \u00ablock table\u00bb. E questo bloccher\u00e0 esplicitamente, cio\u00e8 in modalit\u00e0 ACCESS SHARE, eseguiamo lock table. E se avvio PSQL in background, avvio in questo modo una seconda sessione dalla mia prima sessione. Cosa faccio qui? Passo a un'altra sessione e le dico \u00abfammi vedere lockview per questa richiesta\u00bb. E qui ho AccessShareLock in questa tabella. \u00c8 esattamente ci\u00f2 che ho richiesto. E dice che il blocco \u00e8 stato assegnato. Molto semplice. <\/p>\n
<\/p>\n
<\/p>\n
Inoltre, se guardiamo nella seconda colonna, non c'\u00e8 nulla. Sono vuote. <\/p>\n
<\/p>\n
<\/p>\n
E se eseguo il comando \u00abSELECT\u00bb, questo \u00e8 un modo implicito (esplicito) di richiedere AccessShareLock. Quindi rilascio la mia tabella e avvio la richiesta, e la richiesta restituisce alcune righe. E in una delle righe vediamo AccessShareLock. Pertanto SELECT genera AccessShareLock nella tabella. E non entra in conflitto praticamente con nulla, perch\u00e9 \u00e8 un blocco di basso livello. <\/p>\n
<\/p>\n
<\/p>\n
E se eseguo SELECT e ho tre tabelle diverse? In precedenza ho eseguito solo una tabella, ora ne eseguo tre: pg_class, pg_namespace e pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
E ora, quando guardo alla richiesta, vedo 9 AccessShareLocks in tre tabelle. Perch\u00e9? In blu sono evidenziate tre tabelle: pg_attribute, pg_class, pg_namespace. Ma puoi anche vedere che tutti gli indici definiti tramite queste tabelle hanno anche AccessShareLock.<\/p>\n
<\/p>\n
E questo \u00e8 un blocco che praticamente non entra in conflitto con altri. E tutto ci\u00f2 che fa \u00e8 semplicemente non permetterci di svuotare la tabella mentre la stiamo selezionando. Ha senso. Cio\u00e8, se stiamo selezionando una tabella, in quel momento scomparire, \u00e8 sbagliato, quindi AccessShare \u00e8 un blocco di basso livello che ci dice \"non eliminare questa tabella finch\u00e9 lavoro.\"<\/strong>. In sostanza, \u00e8 tutto ci\u00f2 che fa. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE \u00e8 un blocco un po' diverso. <\/p>\n
<\/p>\n
<\/p>\n
Prendiamo un esempio. SELECT ROW SHARE \u00e8 un modo di bloccare ogni singola riga separatamente.<\/strong>. In questo modo nessuno pu\u00f2 eliminarle o modificarle mentre le stiamo osservando. <\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
Qui diciamo che il blocco \u00e8 utilizzato da noi.<\/p>\n
<\/p>\n
<\/p>\n
Quindi, il blocco esclusivo dice esplicitamente che \u00e8 esclusivo. E anche se elimini una riga da questa tabella, questo accadr\u00e0, come puoi vedere. <\/p>\n
<\/p>\n
<\/p>\n
SHARE EXCLUSIVE \u00e8 un blocco pi\u00f9 lungo.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Questo \u00e8 il comando ANALYZE, che sar\u00e0 usato dall'analizzatore.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK - puoi bloccare esplicitamente in modalit\u00e0 condivisa.<\/p>\n
<\/p>\n
<\/p>\n
Puoi anche creare un indice unico. E l\u00ec puoi vedere SHARE LOCK, che fa parte di questo. E blocca la tabella e applica SHARE LOCK su di essa.<\/p>\n
<\/p>\n
Per impostazione predefinita, SHARE LOCK sulla tabella significa che altre persone possono leggere la tabella, ma nessuno pu\u00f2 modificarla. Ed \u00e8 proprio ci\u00f2 che accade quando crei un indice unico.<\/strong><\/p>\n<\/p>\n
Se creo un indice unico concurrently, avr\u00f2 un altro tipo di blocco, perch\u00e9, come ricordi, l'uso di indici concurrently riduce la necessit\u00e0 di blocchi. E se utilizzo un blocco normale, con un indice normale, ostacoler\u00f2 cos\u00ec la scrittura nell'indice della tabella durante la sua creazione. Se utilizzo un indice concurrently, dovr\u00f2 usare un altro tipo di blocco. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE - pu\u00f2 anche essere impostato esplicitamente.<\/p>\n
<\/p>\n
<\/p>\n
Oppure possiamo creare una regola, cio\u00e8 prendere un caso specifico in cui sar\u00e0 utilizzato.<\/p>\n
<\/p>\n
<\/p>\n
Il blocco EXCLUSIVE significa che nessun altro potr\u00e0 modificare la tabella. <\/p>\n
<\/p>\n
<\/p>\n
Qui vediamo diversi tipi di blocchi. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, ad esempio, \u00e8 un comando di blocco. Ad esempio, se stai facendo CLUSTER table<\/code>, questo significher\u00e0 che nessuno potr\u00e0 scrivere in essa. E blocca non solo la tabella stessa, ma anche gli indici.<\/p>\n<\/p>\n
<\/p>\n
Questa \u00e8 la seconda pagina del blocco ACCESS EXCLUSIVE, dove vediamo specificamente cosa blocca nella tabella. Blocca le singole righe nella tabella, il che \u00e8 piuttosto interessante.<\/p>\n
<\/p>\n
Queste sono tutte le informazioni di base che volevo fornire. Abbiamo parlato dei blocchi, degli ID delle transazioni, abbiamo discusso degli ID virtuali delle transazioni e degli ID permanenti delle transazioni. <\/p>\n
<\/p>\n
<\/p>\n
Ora passeremo attraverso esempi di blocchi. Questa \u00e8 la parte pi\u00f9 interessante. Vedremo casi molto interessanti. Il mio obiettivo in questa presentazione \u00e8 darvi una migliore comprensione di cosa fa realmente Postgres quando cerca di bloccare diverse cose. Mi sembra che sia molto abile nel bloccare singole parti. <\/p>\n
<\/p>\n
Esaminiamo alcuni esempi specifici.<\/p>\n
<\/p>\n
<\/p>\n
Iniziamo con le tabelle e con una riga nella tabella. Quando inserisco qualcosa, vedo un ExclusiveLock, l'ID della transazione e l'ExclusiveLock sulla tabella. <\/p>\n
<\/p>\n
<\/p>\n
E cosa succede se inserisco altre due righe? Ora abbiamo tre righe nella nostra tabella. Ho inserito una riga e ho ottenuto questo in uscita. Se inserisco ancora due righe, cosa c'\u00e8 di strano qui? C'\u00e8 qualcosa di strano, perch\u00e9 ho aggiunto tre righe a questa tabella, ma ho ancora due righe nella tabella di blocco. E questo, fondamentalmente, \u00e8 il comportamento fondamentale di Postgres.<\/p>\n
<\/p>\n
Molti pensano che se in un database bloccate 100 righe, sar\u00e0 necessario creare 100 voci di blocco. Se blocco 1.000 righe contemporaneamente, avr\u00f2 bisogno di 1.000 di queste richieste. E se devo bloccare un milione o un miliardo? Ma se facciamo cos\u00ec, non funzioner\u00e0 molto bene. Se avete utilizzato un sistema che crea voci di blocco per ogni singola riga, vedete che \u00e8 complicato. Perch\u00e9 dovete definire subito la tabella di blocco, che potrebbe sovraccaricarsi, ma Postgres non fa in questo modo. <\/p>\n
<\/p>\n
E in questa diapositiva \u00e8 molto importante notare che qui viene chiaramente dimostrato che esiste un altro sistema che opera all'interno del MVCC, che blocca singole righe. Pertanto, quando bloccate miliardi di righe, Postgres non crea un miliardo di comandi separati per il blocco. Questo ha un effetto molto positivo sulle prestazioni. <\/p>\n
<\/p>\n
<\/p>\n
E per quanto riguarda l'aggiornamento? Sto aggiornando una riga e puoi notare che ha eseguito immediatamente due operazioni diverse. Ha bloccato la tabella, ma ha anche bloccato l'indice. E doveva bloccare l'indice perch\u00e9 ci sono vincoli univoci su questa tabella. Vogliamo assicurarci che nessuno lo modifichi, quindi lo blocchiamo.<\/p>\n
<\/p>\n
<\/p>\n
E cosa succede se voglio aggiornare due righe? E vediamo che si comporta allo stesso modo. Effettuiamo il doppio degli aggiornamenti, ma esattamente lo stesso numero di righe bloccate. <\/p>\n
<\/p>\n
Se ti interessa sapere come lo fa Postgres, devi ascoltare le mie presentazioni su MVCC, per scoprire come Postgres contrassegna internamente queste righe che modifica. E Postgres ha un modo in cui lo fa, ma non lo fa a livello di blocco delle tabelle, lo fa a un livello inferiore e pi\u00f9 efficiente.<\/p>\n
<\/p>\n
<\/p>\n
E se voglio eliminare qualcosa? Se elimino, ad esempio, una riga e ho ancora i miei due vincoli di blocco, anche se volessi eliminarli tutti, rimarrebbero comunque l\u00ec.<\/p>\n
<\/p>\n
<\/p>\n
E, ad esempio, voglio inserire 1.000 righe e poi eliminare o aggiungere altre 1.000 righe, le singole righe che aggiungo o modifico non vengono registrate qui. Vengono registrate a un livello inferiore all'interno della stessa riga. E durante la presentazione su MVCC ne ho parlato nei dettagli. Ma \u00e8 molto importante, quando analizzi i blocchi, assicurarti che tu abbia un blocco a livello di tabella e che qui non vedi come vengono registrate singole righe. <\/p>\n
<\/p>\n
<\/p>\n
E per quanto riguarda il blocco esplicito?<\/p>\n
<\/p>\n
<\/p>\n
Se faccio clic su 'aggiorna', ho due righe bloccate. E se le seleziono tutte e clicco su 'aggiorna tutto', ho comunque due registrazioni di blocco. <\/p>\n
<\/p>\n
<\/p>\n
Non creiamo registrazioni separate per ogni riga. Perch\u00e9 cos\u00ec la performance scende, potrebbe essercene troppo. E potremmo trovarci in una situazione spiacevole. <\/p>\n
<\/p>\n
<\/p>\n
E lo stesso vale se facciamo un shared, possiamo farlo per tutte le 30 volte. <\/p>\n
<\/p>\n
<\/p>\n
Ripristiniamo la nostra tabella, eliminiamo tutto, poi reinseriamo una riga.<\/p>\n
<\/p>\n
<\/p>\n
Un altro tipo di comportamento che si osserva in Postgres \u00e8 un comportamento molto noto e desiderato: si pu\u00f2 effettuare un update o una select. E si pu\u00f2 fare contemporaneamente. E la select non blocca l'update, e viceversa. Diciamo al lettore di non bloccare chi scrive, e chi scrive non blocca il lettore. <\/p>\n
<\/p>\n
Vi mostrer\u00f2 un esempio di questo. Ora far\u00f2 una selezione. Poi faremo un INSERT. E poi potrete vedere \u2013 694. Potrete vedere l'ID della transazione che ha effettuato questo inserimento. Ed \u00e8 cos\u00ec che funziona. <\/p>\n
<\/p>\n
<\/p>\n
E se ora guardo il mio ID di backend, \u00e8 diventato \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
E posso vedere che 695 appare nella mia tabella. <\/p>\n
<\/p>\n
<\/p>\n
E se eseguo un aggiornamento qui in questo modo, ottengo un altro caso. In questo caso, 695 \u00e8 un blocco esclusivo, e l'update ha lo stesso comportamento, ma non si verifica alcun conflitto tra di essi, il che \u00e8 piuttosto insolito. <\/p>\n
<\/p>\n
E potrete notare che in alto c'\u00e8 un ShareLock, e in basso c'\u00e8 un ExclusiveLock. E entrambe le transazioni sono andate a buon fine.<\/p>\n
<\/p>\n
E bisogna ascoltare la mia presentazione su MVCC per capire come funziona. Ma questa \u00e8 un'illustrazione di come si pu\u00f2 fare tutto questo contemporaneamente, cio\u00e8 effettuare SELECT e UPDATE allo stesso tempo.<\/p>\n
<\/p>\n
<\/p>\n
Facciamo un reset e facciamo un'operazione una volta di pi\u00f9. <\/p>\n
<\/p>\n
<\/p>\n
Se provate a eseguire contemporaneamente due update sulla stessa riga, si bloccher\u00e0. E ricordate, ho detto che il lettore non blocca lo scrittore, e lo scrittore blocca il lettore, ma uno scrittore blocca un altro scrittore. Cio\u00e8, non possiamo fare in modo che due persone aggiornino contemporaneamente la stessa riga. Dobbiamo aspettare che uno di loro finisca. <\/p>\n
<\/p>\n
<\/p>\n
E per illustrare questo, dar\u00f2 un'occhiata alla tabella Lockdemo. E guarderemo una riga. Nella transazione 698.<\/p>\n
<\/p>\n
L'abbiamo aggiornato a 2. 699 \u00e8 il primo aggiornamento. E ha avuto successo o si trova in una transazione in attesa e sta aspettando che confermiamo o annulliamo. <\/p>\n
<\/p>\n
<\/p>\n
Ma guarda un'altra cosa \u2013 2\/51 \u2013 questa \u00e8 la nostra prima transazione, la nostra prima sessione. 3\/112 \u2013 questa \u00e8 la seconda richiesta, che \u00e8 apparsa in alto e ha cambiato questo valore in 3. E se noti, il superiore ha bloccato se stesso, che \u00e8 699. Ma 3\/112 non ha fornito alcun blocco. Nella colonna Lock_mode c'\u00e8 scritto che sta aspettando. Sta aspettando 699. E se guardi dove si trova 699, \u00e8 sopra. E cosa ha fatto la prima sessione? Ha creato un blocco esclusivo sul proprio ID di transazione. \u00c8 cos\u00ec che Postgres funziona. Blocca il proprio ID di transazione. E se vuoi aspettare che qualcuno confermi o annulli, devi aspettare che ci sia una transazione in attesa. Ecco perch\u00e9 possiamo vedere una riga strana. <\/p>\n
<\/p>\n
Guardiamo di nuovo. A sinistra vediamo il nostro ID di elaborazione. Nella seconda colonna vediamo il nostro ID virtuale di transazione, e nella terza vediamo il lock_type. Cosa significa? Fondamentalmente, indica che blocca l'ID di transazione. Ma nota che in tutte le righe in fondo c'\u00e8 scritto relation. Ecco perch\u00e9 hai due tipi di blocchi nella tabella. C'\u00e8 il blocco relation. E c'\u00e8 anche il blocco transactionid, dove ci blocchiamo autonomamente, \u00e8 proprio ci\u00f2 che accade nella prima riga o in fondo, dove transactionid, dove aspettiamo che 699 porti a termine la propria operazione. <\/p>\n
<\/p>\n
Sto osservando cosa sta succedendo qui. E qui stanno accadendo due cose simultaneamente. Stai guardando il blocco per ID di transazione nella prima riga, che blocca se stessa. E blocca se stessa per costringere le persone ad aspettare. <\/p>\n
<\/p>\n
Se guardi la sesta riga, \u00e8 la stessa registrazione della prima. Ecco perch\u00e9 la transazione 699 \u00e8 bloccata. Anche 700 si auto-blocca. E poi nella riga inferiore vedrai che stiamo aspettando che 699 porti a termine la propria operazione.<\/p>\n
<\/p>\n
<\/p>\n
E nel lock_type, tuple vedi dei numeri. <\/p>\n
<\/p>\n
<\/p>\n
Puoi vedere che \u00e8 0\/10. E questo \u00e8 il numero di pagina e anche l'offset di questa specifica riga. <\/p>\n
<\/p>\n
<\/p>\n
E vedi che diventa 0\/11 quando aggiorni. <\/p>\n
<\/p>\n
<\/p>\n
Ma in realt\u00e0 \u2013 \u00e8 0\/10, perch\u00e9 si sta aspettando questa operazione. Abbiamo la possibilit\u00e0 di vedere che \u00e8 quella riga che sto aspettando di confermare. <\/p>\n
<\/p>\n
<\/p>\n
Non appena l'abbiamo confermato e premuto commit, e quando l'aggiornamento \u00e8 terminato, ecco cosa otteniamo di nuovo. La transazione 700 \u00e8 l'unico blocco, non sta aspettando nessun altro, perch\u00e9 \u00e8 stata impegnata. Sta solo aspettando che la transazione si concluda. Non appena la 699 termina, non stiamo aspettando pi\u00f9 niente. E ora la transazione 700 dice che va tutto bene, che tutti i blocchi necessari sono presenti in tutte le tabelle autorizzate. <\/p>\n
<\/p>\n
<\/p>\n
E per complicare ulteriormente il tutto, stiamo creando un altro view, che questa volta ci fornir\u00e0 un'idea gerarchica. Non mi aspetto che tu capisca questa query. Ma ci dar\u00e0 una visione pi\u00f9 chiara di cosa sta succedendo. <\/p>\n
<\/p>\n
<\/p>\n
Questo \u00e8 un view ricorsivo, che ha anche un'altra sezione. E poi restituisce tutto insieme. Usandolo. <\/p>\n
<\/p>\n
<\/p>\n
E se facciamo tre aggiornamenti simultanei e diciamo che la riga ora \u00e8 tre. E cambiamo 3 in 4. <\/p>\n
<\/p>\n
<\/p>\n
Ecco, vediamo 4. E l'ID transazionale 702. <\/p>\n
<\/p>\n
<\/p>\n
Poi cambier\u00f2 4 in 5. E 5 in 6, e 6 in 7. E metto in coda le persone che stanno aspettando che questa singola transazione si concluda.<\/p>\n
<\/p>\n
<\/p>\n
E tutto diventa chiaro. Qual \u00e8 la prima riga? \u00c8 702. Questo \u00e8 l'ID transazionale che ha inizialmente impostato questo valore. E cosa ho scritto nella colonna Granted? Ho segni f<\/code>. Questi sono i miei aggiornamenti, che (5, 6, 7) non possono essere approvati, perch\u00e9 stiamo aspettando che l'ID transazionale 702 si concluda. Abbiamo un blocco sull'ID transazionale. E ci sono 5 blocchi transazionali ID.<\/p>\n<\/p>\n
E se guardi 704, 705, l\u00ec non c'\u00e8 ancora nulla scritto, perch\u00e9 non sanno ancora cosa sta succedendo. Scrivono solo che non hanno idea di cosa stia accadendo. E semplicemente andranno a dormire, perch\u00e9 stanno aspettando che qualcuno finisca e li svegli quando ci sar\u00e0 la possibilit\u00e0 di cambiare la riga. <\/p>\n
<\/p>\n
<\/p>\n
Ecco come appare. \u00c8 chiaro che stanno tutti aspettando la 12a riga. <\/p>\n
<\/p>\n
<\/p>\n
Questo \u00e8 ci\u00f2 che abbiamo visto qui. Ecco 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
Quindi, non appena la prima transazione \u00e8 approvata, puoi vedere qui come funziona la gerarchia. E ora diventa tutto chiaro. Sono tutti liberi. E in realt\u00e0 sono ancora in attesa. <\/p>\n
<\/p>\n
<\/p>\n
Ecco cosa sta succedendo. 702 si blocca. E ora 703 ottiene questa blocco di riga, e poi 704 inizia ad aspettare che 703 si impegni. E anche 705 attende questo. E quando tutto questo si conclude, si auto-puliscono. E vorrei sottolineare che tutti si mettono in coda. Ed \u00e8 molto simile alla situazione di una coda, dove tutti aspettano la prima macchina. La prima macchina si ferma, e tutti si mettono in fila lunga. Poi si muove, poi la macchina successiva pu\u00f2 passare avanti e ottenere il proprio blocco, e cos\u00ec via. <\/p>\n
<\/p>\n
<\/p>\n
E se questo vi \u00e8 sembrato abbastanza complicato, ora parleremo di deadlock. Non so quanti di voi ci siano gi\u00e0 stati. \u00c8 un problema abbastanza comune nei sistemi di database. Ma i deadlock sono il caso in cui una sessione aspetta che un'altra esegua qualcosa. E nel frattempo, l'altra sessione sta aspettando che la prima esegua qualcosa. <\/p>\n
<\/p>\n
E, per esempio, se Ivan dice: \u00abDammi qualcosa\u00bb, e io dico: \u00abNo, te lo dar\u00f2 solo se tu mi dai qualcos'altro\u00bb. E lui risponde: \u00abNo, non te lo dar\u00f2 se tu non mi dai\u00bb. E ci troviamo in una situazione di deadlock. Sono sicuro che Ivan non farebbe cos\u00ec, ma capite il senso, abbiamo due persone che vogliono ottenere qualcosa e non sono pronte a darlo fino a quando l'altra persona non gli d\u00e0 ci\u00f2 che vogliono. E qui non c'\u00e8 soluzione. <\/p>\n
<\/p>\n
E, fondamentalmente, il vostro database deve rilevarlo. E poi \u00e8 necessario chiudere o terminare una delle sessioni, perch\u00e9 altrimenti resteranno bloccate per sempre. E lo vediamo nei database, lo vediamo nei sistemi operativi. E in tutti i luoghi dove abbiamo processi paralleli, ci\u00f2 pu\u00f2 accadere. <\/p>\n
<\/p>\n
<\/p>\n
E ora creeremo due deadlock. Imposteremo 50 e 80. Nella prima riga eseguir\u00f2 un aggiornamento da 50 a 50. Otterr\u00f2 il numero di transazione 710. <\/p>\n
<\/p>\n
<\/p>\n
E poi cambier\u00f2 80 in 81, e 50 in 51. <\/p>\n
<\/p>\n
<\/p>\n
Ecco come apparir\u00e0. E quindi 710 ha il blocco di riga, mentre 711 attende conferma. Lo abbiamo visto quando abbiamo aggiornato. 710 \u00e8 il proprietario della nostra riga. E 711 sta aspettando che 710 completi la transazione.<\/p>\n
<\/p>\n
<\/p>\n
E c'\u00e8 anche scritto su quale riga precisamente avviene il deadlock. Ed \u00e8 qui che inizia a diventare strano.<\/p>\n
<\/p>\n
<\/p>\n
Ora aggiorniamo 80 in 80. <\/p>\n
<\/p>\n
<\/p>\n
Ecco dove iniziano i deadlock. 710 aspetta una risposta da 711, e 711 aspetta 710. E questo non finir\u00e0 bene. Non c'\u00e8 uscita da questa situazione. E si aspetteranno reciprocamente. <\/p>\n
<\/p>\n
<\/p>\n
E questo inizier\u00e0 a causare ritardi. E non lo vogliamo. <\/p>\n
<\/p>\n
<\/p>\n
In Postgres ci sono modi per rilevare quando ci\u00f2 accade. E quando accade, si ottiene un errore come questo. E da questo \u00e8 chiaro che un certo processo aspetta un SHARE LOCK da un altro processo, cio\u00e8 quello bloccato dal processo 711. E quel processo aspettava di ricevere un SHARE LOCK su un certo ID di transazione, bloccato da un determinato processo. Quindi, qui abbiamo una situazione di deadlock.<\/p>\n
<\/p>\n
<\/p>\n
Esistono deadlock a tre vie? \u00c8 possibile? S\u00ec. <\/p>\n
<\/p>\n
<\/p>\n
Inseriamo questi numeri nella tabella. Cambiamo 40 in 40, applichiamo un blocco. <\/p>\n
<\/p>\n
<\/p>\n
Cambiamo 60 in 61, 80 in 81. <\/p>\n
<\/p>\n
<\/p>\n
E poi cambiamo 80, e poi \u2013 boom! <\/p>\n
<\/p>\n
<\/p>\n
E ora 714 aspetta 715. Il 716 aspetta il 715. E non c'\u00e8 nulla che si possa fare.<\/p>\n
<\/p>\n
<\/p>\n
Qui non ci sono pi\u00f9 due persone, ma tre. Voglio qualcosa da te, questo vuole qualcosa dal terzo, e il terzo vuole qualcosa da me. E ci troviamo in un'attesa circolare, perch\u00e9 stiamo tutti aspettando che l'altro completi ci\u00f2 che deve fare. <\/p>\n
<\/p>\n
<\/p>\n
E Postgres sa su quale riga ci\u00f2 avviene. E quindi ti mostrer\u00e0 il seguente messaggio, che indica che hai un problema in cui tre input si bloccano a vicenda. E non ci sono limiti. Questo pu\u00f2 accadere quando 20 record si bloccano a vicenda. <\/p>\n
<\/p>\n
<\/p>\n
Il problema successivo \u00e8 serializzabile. <\/p>\n
<\/p>\n
<\/p>\n
Se si tratta di un blocco serializzabile speciale.<\/p>\n
<\/p>\n
<\/p>\n
E torniamo al 719. Ha un output perfettamente normale. <\/p>\n
<\/p>\n
<\/p>\n
E puoi fare clic per eseguire una transazione serializzabile.<\/p>\n
<\/p>\n
<\/p>\n
E ora capisci che hai un altro tipo di blocco SA \u2013 che significa serializzabile. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
E quindi abbiamo un nuovo tipo di blocco chiamato SARieadLock, che \u00e8 un blocco seriale che consente di inserire seriali.<\/p>\n
<\/p>\n
<\/p>\n
E puoi anche inserire indici unici. <\/p>\n
<\/p>\n
<\/p>\n
In questa tabella abbiamo indici unici.<\/p>\n
<\/p>\n
<\/p>\n
Quindi, se inserisco qui il numero 2, quindi ho 2. Ma nella parte superiore inserisco un altro 2. E puoi vedere che il 721 ha un blocco esclusivo. Ma ora il 722 aspetta che il 721 completi la sua operazione, perch\u00e9 non pu\u00f2 inserire 2 fino a quando non sa cosa succeder\u00e0 con il 721. <\/p>\n
<\/p>\n
<\/p>\n
E se facciamo una subtransazione.<\/p>\n
<\/p>\n
<\/p>\n
Ecco il 723.<\/p>\n
<\/p>\n
<\/p>\n
E se manteniamo il punto e poi lo aggiorniamo, otteniamo un nuovo ID di transazione. Questo \u00e8 un altro comportamento che devi conoscere. Se lo restituiamo, l'ID di transazione viene perso. 724 viene perso. Ma ora abbiamo 725. <\/p>\n
<\/p>\n
E cosa sto cercando di fare qui? Sto cercando di mostrarti esempi di blocchi insoliti che puoi trovare: che si tratti di blocchi serializzabili o di SAVEPOINT, sono diversi tipi di blocchi che appariranno nella tabella dei blocchi. <\/p>\n
<\/p>\n
<\/p>\n
Questo \u00e8 creare blocchi espliciti (chiari), che hanno pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
E vedi che il tipo di blocco \u00e8 elencato come advisory. E qui \u00e8 scritto in rosso \u00abadvisory\u00bb. E puoi bloccare contemporaneamente con pg_advisory_unlock.<\/p>\n
<\/p>\n
<\/p>\n
E per finire, vorrei mostrarti un'altra cosa sconvolgente. Creer\u00f2 un altro tipo. Ma unir\u00f2 la tabella pg_locks con la tabella pg_stat_activity. E perch\u00e9 voglio farlo? Perch\u00e9 mi permetter\u00e0 di vedere tutte le sessioni correnti e verificare quali blocchi stanno aspettando. Ed \u00e8 abbastanza interessante quando mettiamo insieme la tabella dei blocchi e la tabella delle query. <\/p>\n
<\/p>\n
<\/p>\n
E qui creiamo pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
E aggiorniamo una riga di uno. E qui vediamo 724. Poi aggiorniamo la nostra riga a tre. E cosa vedi qui adesso? Queste sono le query, cio\u00e8 vedi l'intera lista di query elencate nella colonna di sinistra. E poi sul lato destro puoi vedere i blocchi e ci\u00f2 che creano. E questo potrebbe essere pi\u00f9 comprensibile per te, cos\u00ec non devi tornare ogni volta a ciascuna sessione per vedere se \u00e8 necessario unirsi o meno. Lo fanno per noi. <\/p>\n
<\/p>\n
Un'altra funzione che \u00e8 molto utile \u00e8 pg_blocking_pids<\/code>. Probabilmente non ne hai mai sentito parlare. Cosa fa? Ci permette di dire che per questa sessione 11740, quali esatti ID dei processi sta aspettando. E puoi vedere che 11740 sta aspettando 724. E 724 \u00e8 in cima. E 11306 \u00e8 il tuo ID processo. Fondamentalmente, questa funzione scorre la tua tabella di blocco. E so che \u00e8 un po' complicato, ma stai riuscendo a capirlo. Fondamentalmente, questa funzione attraversa questa tabella di blocco e cerca di trovare dove si trova questo ID processo, tenendo conto dei blocchi che sta aspettando. E cerca anche di calcolare quale sia l'ID processo di quel processo che aspetta i blocchi. Quindi puoi eseguire questa funzione pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
E questo pu\u00f2 essere molto utile. Lo abbiamo aggiunto solo dalla versione 9.6, quindi questa funzione ha solo 5 anni, ma \u00e8 molto, molto utile. E lo stesso vale per la seconda richiesta. Mostra esattamente ci\u00f2 che dobbiamo vedere. <\/p>\n
<\/p>\n
<\/p>\n
\u00c8 di questo che volevo parlare con te. E come mi aspettavo, abbiamo utilizzato tutto il nostro tempo, perch\u00e9 c'era un numero cos\u00ec elevato di diapositive. E le diapositive sono disponibili per il download. Vorrei ringraziarti per essere stato qui. Sono certo che ti piacer\u00e0 il resto della conferenza, grazie mille!<\/p>\n
<\/p>\n
Domande:<\/p>\n
<\/p>\n
Per esempio, se cerco di aggiornare righe, e una seconda sessione cerca di eliminare l'intera tabella. Da quello che capisco, l\u00e0 deve esserci qualcosa come un intent lock. Esiste qualcosa del genere in Postgres?<\/em><\/p>\n<\/p>\n
<\/p>\n
Torniamo all'inizio. Forse ricordi che quando fai qualsiasi cosa, ad esempio quando esegui un SELECT, diamo un AccessShareLock. E questo impedisce l'eliminazione della tabella. Quindi se, ad esempio, vuoi aggiornare una riga nella tabella o eliminare una riga, qualcuno non pu\u00f2 eliminare l'intera tabella contemporaneamente a questo, perch\u00e9 tu detieni questo AccessShareLock sull'intera tabella e sulla riga. E non appena hai finito, possono eliminarla. Ma finch\u00e9 stai modificando qualcosa, non potranno farlo.<\/p>\n
<\/p>\n
Facciamolo di nuovo. Passiamo all'esempio dell'eliminazione. E vedi come su una riga c'\u00e8 un blocco esclusivo su tutta la tabella. <\/p>\n
<\/p>\n
Sar\u00e0 simile a un lock esclusivo, giusto?<\/em><\/p>\n<\/p>\n
S\u00ec, assomiglia a questo. Capisco di cosa stai parlando. Stai dicendo che, se eseguo un SELECT, ho ShareExclusive, e poi lo traduco in Row Exclusive, diventa un problema? Ma sorprendentemente, non crea un problema. Sembra un aumento del livello di blocco, ma in realt\u00e0, ho un lock che impedisce la cancellazione. E ora, quando faccio questo lock pi\u00f9 potente, continua ancora a impedire la cancellazione. Quindi non \u00e8 che stia salendo. Cio\u00e8, lo impediva anche quando era a un livello inferiore, quindi, quando ne aumento il livello, continua a prevenire la cancellazione della tabella. <\/p>\n
<\/p>\n
Capisco di cosa stai parlando. Non c'\u00e8 un caso di aumento del livello di blocco, dove stai cercando di rimuovere un lock per introdurne uno pi\u00f9 potente. Qui si tratta semplicemente di aumentare ovunque questa prevenzione, quindi non causa alcun conflitto. Ma \u00e8 una buona domanda. Grazie mille per averla posta!<\/p>\n
<\/p>\n
Cosa dobbiamo fare per evitare situazioni di deadlock quando abbiamo molte sessioni e un gran numero di utenti?<\/em><\/p>\n<\/p>\n
Postgres rileva automaticamente le situazioni di deadlock. E automaticamente rimuove una delle sessioni. L'unico modo per evitare situazioni di deadlock \u00e8 bloccare le persone nello stesso ordine. Quindi, quando guardi alla tua applicazione, spesso la causa dei deadlock... Immagina che voglio bloccare due cose diverse. Un'applicazione blocca la tabella 1, mentre un'altra applicazione blocca la tabella 2, e poi la tabella 1. E il modo pi\u00f9 semplice per evitare deadlock \u00e8 esaminare la tua applicazione e cercare di assicurarti che il blocco avvenga nello stesso ordine in tutte le applicazioni. E questo generalmente elimina l'80% dei problemi, perch\u00e9 persone diverse scrivono queste applicazioni. E se li blocchi nello stesso ordine, non ti trovi di fronte a situazioni di deadlock.<\/p>\n
<\/p>\n
Grazie mille per il tuo intervento! Hai parlato di vacuum full e, se ho capito bene, vacuum full riorganizza l'ordine delle righe in uno storage separato, quindi mantiene le voci attuali inalterate. Ma perch\u00e9 vacuum full richiede l'accesso in lock esclusivo e perch\u00e9 confligge con le operazioni di scrittura?<\/em><\/p>\n<\/p>\n
\u00c8 una buona domanda. La ragione \u00e8 che vacuum full prende la tabella. E noi, in sostanza, creiamo una nuova versione della tabella. E la tabella sar\u00e0 nuova. Quindi, in effetti, questa sar\u00e0 completamente una nuova versione della tabella. E il problema \u00e8 che, quando facciamo ci\u00f2, non vogliamo che le persone la leggano, perch\u00e9 abbiamo bisogno che vedano la nuova tabella. E quindi si collega alla domanda precedente. Se potessimo leggere contemporaneamente, non potremmo spostare le persone sulla nuova tabella. Dovremmo aspettare che tutti finissero di leggere questa tabella e quindi, in sostanza, \u00e8 una situazione di lock exclusive.
<\/p>\n
\u00c8 possibile aggiungere un timeout di locking in Postgres? In Oracle posso, ad esempio, scrivere 'seleziona per aggiornare' e aspettare 50 secondi prima di aggiornare. Questo era buono per l'applicazione. Ma in Postgres devo farlo immediatamente e non aspettare affatto, oppure aspettare fino a un certo momento.<\/em> <\/p>\n<\/p>\n
S\u00ec, puoi selezionare un timeout per i tuoi blocchi, sui tuoi locks. Puoi anche emettere un comando no way, che sar\u00e0 \u2026, se non puoi ottenere immediatamente un blocco. Quindi o lock timeout, o altro che ti permetta di farlo. Non si fa a livello sintattico. Si fa come variabile sul server. A volte non \u00e8 utilizzabile.<\/p>\n
<\/p>\n
Puoi aprire il 75\u00b0 slide?<\/em> <\/p>\n<\/p>\n
S\u00ec.<\/p>\n
<\/p>\n
<\/p>\n
E la mia domanda \u00e8 la seguente. Perch\u00e9 entrambi i processi di aggiornamento aspettano il 703?<\/em><\/p>\n<\/p>\n
E questa \u00e8 una domanda interessante. Non capisco, tra l'altro, perch\u00e9 Postgres si comporti in questo modo. Quando \u00e8 stato creato 703, si aspettava 702. E quando 704 e 705 compaiono, sembra che non sappiano cosa stanno aspettando, perch\u00e9 non c'\u00e8 ancora nulla. E Postgres fa in questo modo: quando non riesci a ottenere un blocco, scrive \"E qual \u00e8 il senso di elaborarti?\", perch\u00e9 stai comunque aspettando qualcuno. Quindi lasciamolo semplicemente pendere in aria, non lo aggiorna proprio. Ma cosa \u00e8 successo qui? Appena 702 ha completato il processo e 703 ha ottenuto il suo blocco, il sistema \u00e8 tornato indietro. E ha detto che ora abbiamo due persone che stanno aspettando. E poi aggiorniamo entrambe insieme. E indichiamo che entrambe stanno aspettando. <\/p>\n
<\/p>\n
Non so perch\u00e9 Postgres agisca in questo modo. Ma c'\u00e8 un problema che si chiama f\u2026. Mi sembra che non sia un termine russo. \u00c8 quando tutti aspettano un solo lock, anche se ci sono 20 istanze che aspettano il lock. E all'improvviso si svegliano tutte insieme. E tutti iniziano a cercare di reagire. Ma il sistema fa s\u00ec che tutti aspettino 703. Perch\u00e9 stanno tutti aspettando, e li mettiamo in fila immediatamente. E se appare qualche altra nuova richiesta, che \u00e8 stata formata dopo, per esempio 707, ci sar\u00e0 di nuovo un vuoto. <\/p>\n
<\/p>\n
E mi sembra che questo venga fatto in modo da poter dire che a questo punto 702 sta aspettando 703, mentre per chi arriva dopo non ci sar\u00e0 alcuna registrazione in questo campo. Ma appena il primo in attesa se ne va, quelli che stavano aspettando in quel momento prima dell'aggiornamento ricevono lo stesso marcatore. E quindi, mi sembra che questo sia fatto per gestire in ordine, in modo che siano disposti correttamente. <\/p>\n
<\/p>\n
Io l'ho sempre considerato un fenomeno piuttosto strano. Perch\u00e9 qui, ad esempio, non li elenchiamo affatto. Ma, mi sembra, ogni volta che diamo un nuovo lock, guardiamo a tutti coloro che stanno aspettando. Quindi li mettiamo tutti in fila. E poi chiunque nuovi arrivi entra in coda solo quando la persona successiva ha finito di essere elaborata. Domanda molto buona. Grazie mille per la domanda!<\/p>\n
<\/p>\n
Mi sembra molto pi\u00f9 logico quando 705 aspetta 704.<\/em> <\/p>\n<\/p>\n
Ma il problema qui \u00e8 il seguente. Tecnologicamente, puoi svegliare o l'uno o l'altro. E quindi sveglieremo l'uno o l'altro. Ma cosa succede nel funzionamento del sistema? Vedi, come 703 in cima ha bloccato il proprio ID transazionale. \u00c8 cos\u00ec che funziona Postgres. E 703 viene bloccato dal proprio ID transazionale, quindi, se qualcuno vuole aspettare, aspetter\u00e0 703. E, in sostanza, 703 termina. E solo dopo che si completa, uno dei processi si risveglia. E non sappiamo quale sar\u00e0 quel processo. Poi li gestiamo gradualmente. Ma non \u00e8 chiaro quale processo si risveglier\u00e0 per primo, perch\u00e9 potrebbe essere qualsiasi di questi processi. In sostanza, avevamo uno scheduler che diceva che ora possiamo risvegliare qualsiasi di questi processi. Semplicemente scegliamo uno a caso. Quindi entrambi devono essere contrassegnati, perch\u00e9 possiamo risvegliare uno di essi. <\/p>\n
<\/p>\n
E il problema \u00e8 che abbiamo un'infinit\u00e0 di CP. E quindi \u00e8 molto probabile che possiamo risvegliare quello pi\u00f9 recente. E se, ad esempio, risvegliamo quello pi\u00f9 recente, allora aspetteremo chi ha appena ottenuto il blocco, quindi non possiamo determinare qual \u00e8 esattamente il primo a essere risvegliato. Creiamo semplicemente una situazione del genere, e il sistema li risveglier\u00e0 in ordine casuale. <\/p>\n
<\/p>\n
C'\u00e8 articoli sui locks di Egor Rogov<\/a><\/noindex>. Dai un'occhiata, sono anche interessanti e utili. L'argomento \u00e8, ovviamente, terribilmente complesso. Grazie mille, Bruce!<\/em><\/p>\nFonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2020 \u0433\u043e\u0434\u0430 \u0411\u0440\u044e\u0441\u0430 \u041c\u043e\u043c\u0436\u0438\u0430\u043d\u0430 "Unlocking the Postgres Lock Manager". (\u041f\u0440\u0438\u043c\u0435\u0447\u0430\u043d\u0438\u0435: \u0412\u0441\u0435 SQL \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438\u0437 \u0441\u043b\u0430\u0439\u0434\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043f\u043e \u044d\u0442\u043e\u0439 \u0441\u0441\u044b\u043b\u043a\u0435: http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql) \u041f\u0440\u0438\u0432\u0435\u0442! \u0417\u0430\u043c\u0435\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0441\u043d\u043e\u0432\u0430 \u0431\u044b\u0442\u044c \u0437\u0434\u0435\u0441\u044c \u0432 \u0420\u043e\u0441\u0441\u0438\u0438. \u042f \u043f\u0440\u043e\u0448\u0443 \u043f\u0440\u043e\u0449\u0435\u043d\u0438\u0435, \u0447\u0442\u043e \u044f \u043d\u0435 \u0441\u043c\u043e\u0433 \u043f\u0440\u0438\u0435\u0445\u0430\u0442\u044c \u0432 \u043f\u0440\u043e\u0448\u043b\u043e\u043c \u0433\u043e\u0434\u0443, \u043d\u043e \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0443 \u0418\u0432\u0430\u043d\u0430 \u0438 \u0443 \u043c\u0435\u043d\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043f\u043b\u0430\u043d\u044b. \u042f, \u043d\u0430\u0434\u0435\u044e\u0441\u044c, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":87955,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87954","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Unlocking](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n