http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Vediamo. Il numero della transazione \u00e8 evidenziato in rosso. Qui \u00e8 mostrata la funzione SELECT pg_back. Essa restituisce la mia transazione e l'ID di questa transazione. <\/p>\n
<\/p>\n
Un altro aspetto: se ti piace questa presentazione e desideri avviarla nel tuo database, puoi seguire questo link evidenziato in rosa e scaricare il SQL per questa presentazione. Puoi semplicemente eseguirlo 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. \u00c8 il numero che le abbiamo assegnato. E c'\u00e8 anche un altro tipo di ID della transazione in Postgres, chiamato ID virtuale della transazione.<\/p>\n
<\/p>\n
Dobbiamo comprenderlo. \u00c8 molto importante, altrimenti non saremo in grado di capire il blocco in Postgres.<\/p>\n
<\/p>\n
L'ID virtuale della transazione \u00e8 un ID della transazione che non contiene valori fissi. Ad esempio, se eseguo un comando SELECT, probabilmente non cambier\u00f2 il database e non bloccher\u00f2 nulla. Pertanto, quando eseguiamo un semplice SELECT, non diamo a questa transazione un ID fisso. Le diamo solo un ID virtuale.<\/p>\n
<\/p>\n
E questo migliora le prestazioni di Postgres, ottimizzando le capacit\u00e0 di pulizia, quindi l'ID virtuale della transazione \u00e8 composto da due numeri. Il primo numero prima della barra \u00e8 l'ID del backend. A destra vediamo semplicemente un contatore.<\/p>\n
<\/p>\n
<\/p>\n
Quindi, se eseguo una richiesta, dice che l'ID del backend \u00e8 2. <\/p>\n
<\/p>\n
<\/p>\n
Se eseguo una serie di tali transazioni, vediamo che il contatore aumenta ogni volta che eseguo una richiesta. Ad esempio, quando eseguo la richiesta 2\/10, 2\/11, 2\/12 e cos\u00ec via. <\/p>\n
<\/p>\n
<\/p>\n
Tenete presente che ci sono due colonne. A sinistra vediamo l'ID virtuale della transazione \u2013 2\/12. A destra abbiamo l'ID permanente della transazione. E questo campo \u00e8 vuoto. E questa transazione non modifica il database. Pertanto, non le assegno un ID permanente della transazione.<\/p>\n
<\/p>\n
<\/p>\n
Non appena eseguo il comando di analisi (ANALYZE), la stessa richiesta mi fornisce un ID permanente della transazione. Vedete come \u00e8 cambiato. Prima non avevo questo ID, ora \u00e8 apparso.<\/p>\n
<\/p>\n
<\/p>\n
Quindi, qui c'\u00e8 un'altra richiesta, un'altra transazione. Il numero virtuale della transazione \u00e8 2\/13. E se chiedo l'ID permanente della transazione, quando eseguo la richiesta, lo ottengo. <\/p>\n
<\/p>\n
<\/p>\n
Quindi, per chiarire. Abbiamo un ID virtuale della transazione e un ID permanente della transazione. \u00c8 importante comprendere questo concetto per capire il comportamento di Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Passiamo alla terza sezione. Qui esamineremo i diversi tipi di blocchi in Postgres. Non \u00e8 molto interessante. L'ultima sezione sar\u00e0 sicuramente pi\u00f9 coinvolgente. Ma dobbiamo trattare le basi, altrimenti non comprenderemo ci\u00f2 che verr\u00e0 dopo. <\/p>\n
<\/p>\n
Affronteremo questa sezione, guarderemo ogni tipo di blocco. Vi mostrer\u00f2 esempi di come vengono impostati, come funzionano, e vi presenter\u00f2 alcune query che potete usare per osservare come funziona il blocco in Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Per creare una query e vedere cosa succede in Postgres, dobbiamo eseguire una query nella vista di sistema. In questo caso, evidenziamo in rosso pg_lock. Pg_lock \u00e8 una tabella di sistema che ci indica quali blocchi sono attualmente attivi in Postgres.<\/p>\n
<\/p>\n
Tuttavia, \u00e8 molto difficile per me mostrarti pg_lock da solo, perch\u00e9 \u00e8 piuttosto complesso. Perci\u00f2, ho creato una vista che mostra pg_locks. Inoltre, esegue per me alcune operazioni che mi permettono di capire meglio. Cio\u00e8, esclude i miei blocchi, la mia sessione ecc. \u00c8 semplicemente SQL standard e permette di mostrarti 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 \u2013 lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Quindi, abbiamo creato una tabella chiamata Lockdemo. E abbiamo inserito una riga. Questa \u00e8 la nostra tabella di esempio. Creeremo sezioni per mostrarti semplicemente esempi di blocchi. <\/p>\n
<\/p>\n
<\/p>\n
Quindi, una riga, una colonna. Il primo tipo di blocco si chiama ACCESS SHARE. Questo \u00e8 il blocco meno restrittivo. Significa che praticamente non entra in conflitto con gli altri blocchi.<\/p>\n
<\/p>\n
Se vogliamo definire esplicitamente il blocco, eseguiamo il comando \"lock table\". E questo bloccher\u00e0 esplicitamente, cio\u00e8 in modalit\u00e0 ACCESS SHARE, eseguiamo lock table. E se avvio PSQL in background, avvio cos\u00ec una seconda sessione dalla mia prima sessione. Cosa faccio qui? Passo a un'altra sessione e le dico \"mostrami lockview per questa query\". Qui ho AccessShareLock in questa tabella. \u00c8 proprio quello che avevo 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 \"SELECT\", questo \u00e8 un modo implicito (esplicito) per richiedere AccessShareLock. Quindi rilascio la mia tabella e avvio la query, e la query restituisce diverse righe. In una delle righe vediamo AccessShareLock. Cos\u00ec SELECT chiama AccessShareLock nella tabella. E non entra praticamente in conflitto con nulla, perch\u00e9 \u00e8 un blocco di basso livello. <\/p>\n
<\/p>\n
<\/p>\n
Cosa succede se eseguo SELECT e ho tre tabelle diverse? In precedenza eseguivo solo una tabella, ora ne eseguo tre: pg_class, pg_namespace e pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
E ora, mentre guardo la richiesta, vedo 9 AccessShareLocks in tre tabelle. Perch\u00e9? Le tre tabelle sono evidenziate in blu: pg_attribute, pg_class, pg_namespace. Ma puoi anche vedere che tutti gli indici definiti attraverso queste tabelle hanno anch'essi un AccessShareLock.<\/p>\n
<\/p>\n
E questa \u00e8 una lock che praticamente non confligge con altre. E tutto ci\u00f2 che fa \u00e8 semplicemente impedirci di resettare la tabella mentre la stiamo selezionando. Ha senso. Cio\u00e8, se stiamo selezionando una tabella, scompare in quel momento, il che non \u00e8 corretto. AccessShare \u2013 \u044d\u0442\u043e \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0430 \u043d\u0438\u0437\u043a\u043e\u0433\u043e \u0443\u0440\u043e\u0432\u043d\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c "\u043d\u0435 \u0443\u0434\u0430\u043b\u044f\u0439\u0442\u0435 \u044d\u0442\u0443 \u0442\u0430\u0431\u043b\u0438\u0446\u0443, \u043f\u043e\u043a\u0430 \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e"<\/strong>. Fondamentalmente, \u00e8 tutto ci\u00f2 che fa. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE \u00e8 un lock un po' diverso. <\/p>\n
<\/p>\n
<\/p>\n
Facciamo un esempio. SELECT ROW SHARE \u00e8 un modo di bloccare ogni singola riga.<\/strong>. Cos\u00ec nessuno pu\u00f2 eliminarle o modificarle mentre le stiamo visualizzando. <\/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 se si elimina una riga in questa tabella, proprio questo succeder\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 (ANALYZE) \u00e8 il comando dell'analizzatore che verr\u00e0 utilizzato.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK \u2013 puoi esplicitamente bloccare in modalit\u00e0 share.<\/p>\n
<\/p>\n
<\/p>\n
Puoi anche creare un indice unico. E l\u00ec puoi vedere SHARE LOCK, che fa parte di esso. Blocca la tabella e imposta su di essa il blocco SHARE LOCK.<\/p>\n
<\/p>\n
Per impostazione predefinita, la SHARE LOCK su una tabella significa che altre persone possono leggerla, ma nessuno pu\u00f2 modificarla. E questo \u00e8 esattamente 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, un indice normale, impedir\u00f2 in questo modo 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 \u2013 pu\u00f2 essere impostato esplicitamente.<\/p>\n
<\/p>\n
<\/p>\n
Oppure possiamo creare una regola, cio\u00e8 prendere un caso specifico in cui sar\u00e0 utilizzata.<\/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 vari tipi di blocchi. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, ad esempio, \u00e8 un comando di blocco. Per esempio, se fai CLUSTER table<\/code>, questo significher\u00e0 che nessuno potr\u00e0 scriverci. E blocca non solo la tabella stessa, ma anche gli indici.<\/p>\n<\/p>\n
<\/p>\n
Questa \u00e8 la seconda pagina di blocco ACCESS EXCLUSIVE, dove vediamo specificamente cosa sta bloccando nella tabella. Blocca singole righe della tabella, il che \u00e8 piuttosto interessante.<\/p>\n
<\/p>\n
Queste sono tutte le informazioni di base che volevo fornire. Abbiamo parlato di 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 alcuni esempi di blocco. Questa \u00e8 la parte pi\u00f9 interessante. Esamineremo casi molto interessanti. Il mio obiettivo in questa presentazione \u00e8 darvi una migliore comprensione di ci\u00f2 che Postgres fa realmente quando cerca di bloccare determinate cose. Penso che sia molto abile nel bloccare parti specifiche. <\/p>\n
<\/p>\n
Analizziamo alcuni esempi specifici.<\/p>\n
<\/p>\n
<\/p>\n
Iniziamo con le tabelle e con una riga nella tabella. Quando inserisco qualcosa, mi appare ExclusiveLock, l'ID della transazione e ExclusiveLock sulla tabella. <\/p>\n
<\/p>\n
<\/p>\n
E se inserisco altre due righe? Ora abbiamo tre righe nella nostra tabella. Ho inserito una riga e ho ottenuto questo in output. E se inserisco altre due righe, cosa c'\u00e8 di strano qui? C'\u00e8 una stranezza, perch\u00e9 ho aggiunto tre righe a questa tabella, ma ho ancora due righe nella tabella di blocco. E questo \u00e8, in sostanza, il comportamento fondamentale di Postgres.<\/p>\n
<\/p>\n
Molti pensano che se nella base di dati bloccate 100 righe, sar\u00e0 necessario creare 100 inserimenti di blocco. Se blocco subito 1.000 righe, mi serviranno 1.000 richieste del genere. E se devo bloccare un milione o un miliardo. Ma se procediamo in questo modo, non funzioner\u00e0 molto bene. Se avessi un sistema che genera inserti di blocco per ciascuna riga, vedresti che \u00e8 complicato. Perch\u00e9 dovresti definire subito una tabella di blocco che pu\u00f2 riempirsi, ma Postgres non funziona in questo modo. <\/p>\n
<\/p>\n
In questo slide \u00e8 molto importante notare che qui viene chiaramente dimostrato che esiste un altro sistema che opera all'interno di MVCC, il quale blocca righe specifiche. Quindi, quando bloccate miliardi di righe, Postgres non genera miliardo di comandi separati per il blocco. Questo ha un impatto molto positivo sulle prestazioni. <\/p>\n
<\/p>\n
<\/p>\n
E per quanto riguarda l'aggiornamento? Ora sto aggiornando una riga e potete 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 restrizioni uniche su questa tabella. Vogliamo assicurarci che nessuno la modifichi, quindi la bloccano.<\/p>\n
<\/p>\n
<\/p>\n
E cosa succede se voglio aggiornare due righe? Vediamo che si comporta allo stesso modo. Eseguiamo il doppio degli aggiornamenti, ma esattamente lo stesso numero di righe bloccate. <\/p>\n
<\/p>\n
Se sei curioso di sapere come fa Postgres, devi ascoltare le mie presentazioni su MVCC per scoprire come Postgres etichetta internamente le righe che modifica. E Postgres ha un modo per farlo, ma non lo fa a livello di blocco delle tabelle, lo fa a un livello pi\u00f9 basso 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 input per il blocco, anche se volessi eliminarli tutti, essi sono comunque presenti.<\/p>\n
<\/p>\n
<\/p>\n
Per esempio, se 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 pi\u00f9 basso all'interno della riga stessa. Durante la mia presentazione su MVCC ne ho parlato in dettaglio. Ma \u00e8 molto importante, quando analizzi i blocchi, assicurarti che hai un blocco a livello di tabella e che qui non vedi come viene registrata ogni singola riga. <\/p>\n
<\/p>\n
<\/p>\n
E per quanto riguarda il blocco esplicito?<\/p>\n
<\/p>\n
<\/p>\n
Se clicco su \u00abaggiorna\u00bb, ho due righe bloccate. E se le seleziono tutte e premo \u00abaggiorna tutto\u00bb, ho comunque due registrazioni di blocco. <\/p>\n
<\/p>\n
<\/p>\n
Non creiamo registrazioni separate per ogni singola riga. Perch\u00e9 altrimenti le prestazioni calano, ci potrebbero essere troppe. E potremmo trovarci in una situazione scomoda. <\/p>\n
<\/p>\n
<\/p>\n
E lo stesso vale se facciamo in modalit\u00e0 condivisa, possiamo farlo per tutte e 30 le volte. <\/p>\n
<\/p>\n
<\/p>\n
Ripristiniamo la nostra tabella, cancelliamo tutto, poi reinseriamo una riga.<\/p>\n
<\/p>\n
<\/p>\n
Un altro tipo di comportamento che vediamo in Postgres \u00e8 molto noto e desiderato: \u00e8 quello che possiamo effettuare un update o un select. E possiamo farlo simultaneamente. E il 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 mostro 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 eseguito questo inserimento. E cos\u00ec 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 il 695 appare nella mia tabella. <\/p>\n
<\/p>\n
<\/p>\n
E se aggiorno 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 creano conflitti tra loro, il che \u00e8 piuttosto insolito. <\/p>\n
<\/p>\n
E puoi notare che in alto c'\u00e8 ShareLock, e in basso c'\u00e8 ExclusiveLock. E entrambe le transazioni sono andate a buon fine.<\/p>\n
<\/p>\n
Dovrei ascoltare la mia presentazione su MVCC per capire come funziona. Ma questa \u00e8 un'illustrazione di ci\u00f2 che puoi fare contemporaneamente, ovvero eseguire SELECT e UPDATE allo stesso tempo.<\/p>\n
<\/p>\n
<\/p>\n
Facciamo un reset e facciamo un'operazione di nuovo. <\/p>\n
<\/p>\n
<\/p>\n
Se provi a eseguire due update contemporaneamente sulla stessa riga, verr\u00e0 bloccata. E ricorda, ho detto che chi legge non blocca chi scrive, ma chi scrive blocca chi legge. Ma un scrittore blocca un altro scrittore. Cio\u00e8, non possiamo fare in modo che due persone aggiornino la stessa riga contemporaneamente. Bisogna 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
Lo abbiamo aggiornato a 2. 699 \u00e8 il primo aggiornamento. E ha avuto successo oppure \u00e8 in attesa di transazione e aspetta che confermiamo o annulliamo. <\/p>\n
<\/p>\n
<\/p>\n
Ma guardate un'altra cosa \u2013 2\/51 \u2013 \u00e8 la nostra prima transazione, la nostra prima sessione. 3\/112 \u2013 \u00e8 la seconda richiesta, che \u00e8 apparsa sopra e ha cambiato questo valore in 3. E se notate, l'alto si \u00e8 bloccato da solo, che \u00e8 699. Ma 3\/112 non ha fornito alcun blocco. Nella colonna Lock_mode c'\u00e8 scritto che \u00e8 in attesa. Sta aspettando 699. E se guardate 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 volete aspettare che qualcuno confermi o annulli, dovete aspettare una transazione in attesa. Ecco perch\u00e9 possiamo vedere una riga strana. <\/p>\n
<\/p>\n
Rivediamo un attimo. A sinistra vediamo il nostro ID di elaborazione. Nella seconda colonna troviamo il nostro ID virtuale della transazione, e nella terza vediamo il lock_type. Cosa significa? Fondamentalmente, indica che blocca l'ID della transazione. Ma notate che in tutte le righe in basso c'\u00e8 scritto relation. E quindi avete due tipi di blocco nella tabella. Esiste il blocco relation. E c'\u00e8 anche il blocco transactionid, dove bloccate autonomamente, questo \u00e8 esattamente ci\u00f2 che accade nella prima riga o nella parte inferiore, dove transactionid, dove ci aspettiamo che 699 completi la sua operazione. <\/p>\n
<\/p>\n
Vedo cosa sta accadendo qui. E qui si svolgono due cose contemporaneamente. Stai osservando il blocco per l'ID della transazione nella prima riga, che si blocca da solo. E si blocca da solo per costringere le persone ad aspettare. <\/p>\n
<\/p>\n
Se guardi la sesta riga, troverai la stessa voce della prima. E quindi la transazione 699 \u00e8 bloccata. Anche 700 si blocca da solo. E poi nella riga inferiore vedrete che stiamo aspettando che 699 completi la sua operazione.<\/p>\n
<\/p>\n
<\/p>\n
E nel lock_type, tuple vedete dei numeri. <\/p>\n
<\/p>\n
<\/p>\n
Puoi vedere che sono 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 aggiorniamo. <\/p>\n
<\/p>\n
<\/p>\n
Ma in realt\u00e0 \u00e8 0\/10, perch\u00e9 stiamo aspettando che questa operazione si completi. Abbiamo la possibilit\u00e0 di vedere che \u00e8 quella riga che sto aspettando per confermare. <\/p>\n
<\/p>\n
<\/p>\n
Una volta che l'abbiamo confermata e premuto il commit, e quando l'aggiornamento \u00e8 finito, questo \u00e8 ci\u00f2 che otteniamo di nuovo. La transazione 700 \u00e8 l'unico blocco, non sta aspettando nessun altro perch\u00e9 \u00e8 stata confermata. Sta solo aspettando che la transazione si completi. Una volta che 699 finisce, non stiamo pi\u00f9 aspettando nulla. E ora la transazione 700 dice che va tutto bene, tutte le chiavi necessarie sono disponibili in tutte le tabelle autorizzate. <\/p>\n
<\/p>\n
<\/p>\n
E per complicare ulteriormente le cose, creiamo un'altra vista, che questa volta ci fornir\u00e0 una gerarchia. Non mi aspetto che tu capisca questa query. Ma ci dar\u00e0 una visione pi\u00f9 chiara di ci\u00f2 che sta accadendo. <\/p>\n
<\/p>\n
<\/p>\n
Questa \u00e8 una vista ricorsiva, che ha anche un'altra sezione. E poi riunisce tutto di nuovo. Utilizziamo questo. <\/p>\n
<\/p>\n
<\/p>\n
E se facessimo tre aggiornamenti simultanei e dicessimo che la riga ora \u00e8 pari a tre. E cambiamo 3 in 4. <\/p>\n
<\/p>\n
<\/p>\n
E ora vediamo 4. E l'ID transazionale \u00e8 702. <\/p>\n
<\/p>\n
<\/p>\n
Poi cambier\u00f2 4 in 5. E 5 in 6, e 6 in 7. E metto in fila una serie di persone che aspettano che questa singola transazione si concluda.<\/p>\n
<\/p>\n
<\/p>\n
E tutto diventa chiaro. Qual \u00e8 la prima fila? \u00c8 702. Questo \u00e8 l'ID transazionale che ha originariamente impostato questo valore. E cosa ho scritto nella colonna Granted? Ho dei segni f<\/code>. Questi sono i miei aggiornamenti (5, 6, 7) che non possono essere approvati, perch\u00e9 stiamo aspettando che l'ID transazionale 702 si concluda. Qui abbiamo un blocco dell'ID transazionale. E quindi ci sono 5 blocchi dell'ID transazionale.<\/p>\n<\/p>\n
E se guardi 704, 705, l\u00ec non \u00e8 ancora stato scritto nulla, perch\u00e9 non sanno ancora cosa sta accadendo. Scrivono solo che non hanno idea di cosa stia succedendo. E semplicemente andranno a dormire, perch\u00e9 stanno aspettando che qualcuno finisca e li svegli quando ci sar\u00e0 la possibilit\u00e0 di cambiare fila. <\/p>\n
<\/p>\n
<\/p>\n
Ecco come appare. \u00c8 chiaro che stanno tutti aspettando la dodicesima riga. <\/p>\n
<\/p>\n
<\/p>\n
Ecco cosa abbiamo visto qui. Ecco 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
Quindi, una volta che la prima transazione \u00e8 approvata, qui puoi vedere come funziona la gerarchia. Ora tutto diventa chiaro. Tutti si liberano. E sono effettivamente ancora in attesa. <\/p>\n
<\/p>\n
<\/p>\n
Ecco cosa succede. 702 viene committato. Ora 703 acquisisce il blocco della riga, e poi 704 inizia ad aspettare che 703 venga committato. Anche 705 sta aspettando questo. E quando tutto questo si completa, si puliscono da soli. Vorrei far notare che tutti si mettono in fila. \u00c8 molto simile a una situazione di ingorgo, dove tutti aspettano la prima auto. La prima auto si \u00e8 fermata, e tutti si mettono in una lunga fila. Poi si muove, e l'auto successiva pu\u00f2 passare e ricevere il suo blocco, e cos\u00ec via. <\/p>\n
<\/p>\n
<\/p>\n
E se questo vi \u00e8 sembrato poco complesso, parleremo adesso 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 quel caso in cui una sessione attende che un'altra sessione esegua qualcosa. Nel frattempo, l'altra sessione attende che la prima sessione 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 mi dai qualcosa in cambio\u00bb. E lui dice: \u00abNo, non ti dar\u00f2 niente se tu non mi dai qualcosa\u00bb. Ci troviamo quindi in una situazione di stallo. Sono sicuro che Ivan non farebbe una cosa simile, ma capite il senso: due persone vogliono ottenere qualcosa e non sono disposte a cederlo finch\u00e9 l'altra persona non d\u00e0 loro ci\u00f2 che desidera. E qui non c'\u00e8 soluzione. <\/p>\n
<\/p>\n
E, in sostanza, il vostro database deve identificarlo. E poi \u00e8 necessario rimuovere o chiudere una delle sessioni, perch\u00e9 altrimenti rimarranno l\u00ec per sempre. E questo lo vediamo nei database, lo vediamo nei sistemi operativi. E in tutti i luoghi dove abbiamo processi paralleli, pu\u00f2 succedere. <\/p>\n
<\/p>\n
<\/p>\n
E ora creeremo due deadlock. Installeremo 50 e 80. Nella prima riga far\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. Pertanto, 710 ha il blocco della riga, mentre 711 attende una conferma. Lo abbiamo visto quando abbiamo effettuato l'aggiornamento. 710 \u00e8 il proprietario della nostra riga. E 711 attende che 710 completi la transazione.<\/p>\n
<\/p>\n
<\/p>\n
E l\u00ec \u00e8 anche scritto in quale specifica riga si verificano i deadlock. Ed \u00e8 qui che inizia a diventare strano.<\/p>\n
<\/p>\n
<\/p>\n
Ora stiamo aggiornando 80 su 80. <\/p>\n
<\/p>\n
<\/p>\n
Ed \u00e8 qui che iniziano i deadlock. 710 aspetta una risposta da 711, mentre 711 aspetta 710. E questo non avr\u00e0 una buona conclusione. E non c'\u00e8 via d'uscita. Aspetteranno una risposta l'uno dall'altro. <\/p>\n
<\/p>\n
<\/p>\n
E questo inizier\u00e0 a ritardare tutto. E non lo vogliamo. <\/p>\n
<\/p>\n
<\/p>\n
In Postgres ci sono modi per rilevare quando ci\u00f2 accade. E quando succede, si riceve un errore come questo. E da ci\u00f2 \u00e8 chiaro che un certo processo sta aspettando un SHARE LOCK da un altro processo, cio\u00e8 bloccato dal processo 711. E quel processo stava aspettando che venisse dato un SHARE LOCK su un certo ID di transazione ed \u00e8 stato bloccato da un certo processo. Pertanto, qui c'\u00e8 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 su 40, creiamo un blocco. <\/p>\n
<\/p>\n
<\/p>\n
Cambiamo 60 su 61, 80 su 81. <\/p>\n
<\/p>\n
<\/p>\n
E poi cambiamo 80, e poi - boom! <\/p>\n
<\/p>\n
<\/p>\n
E 714 ora aspetta 715. Il 716 attende il 715. E non si pu\u00f2 fare nulla con questo.<\/p>\n
<\/p>\n
<\/p>\n
Qui non ci sono pi\u00f9 due persone, ma gi\u00e0 tre. Voglio qualcosa da te, lui desidera qualcosa dal terzo, e il terzo vuole qualcosa da me. Ci troviamo quindi in un'attesa reciproca, poich\u00e9 tutti aspettiamo che qualcun altro completi ci\u00f2 che deve fare. <\/p>\n
<\/p>\n
<\/p>\n
E Postgres sa in quale riga si verifica. Di conseguenza, ti fornir\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 registrazioni si bloccano a vicenda. <\/p>\n
<\/p>\n
<\/p>\n
Il problema successivo \u00e8 serializzabile. <\/p>\n
<\/p>\n
<\/p>\n
Se c'\u00e8 un blocco serializzabile speciale.<\/p>\n
<\/p>\n
<\/p>\n
E torniamo a 719. Ha un'uscita del tutto normale. <\/p>\n
<\/p>\n
<\/p>\n
E puoi cliccare per effettuare una transazione in modalit\u00e0 serializzabile.<\/p>\n
<\/p>\n
<\/p>\n
E capisci che ora hai un altro tipo di blocco SA \u2013 questo 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 e consente di inserire numeri di serie.<\/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 il numero 2 qui, ho 2. Ma nella parte superiore inserisco un altro 2. E potete vedere che il 721 ha un blocco esclusivo. Ora, per\u00f2, il 722 attende che il 721 completi la sua operazione, perch\u00e9 non pu\u00f2 inserire 2 finch\u00e9 non sa cosa accadr\u00e0 al 721. <\/p>\n
<\/p>\n
<\/p>\n
E se facciamo una subtransazione.<\/p>\n
<\/p>\n
<\/p>\n
Qui abbiamo il 723.<\/p>\n
<\/p>\n
<\/p>\n
E se salviamo il punto e poi lo aggiorniamo, otteniamo un nuovo ID di transazione. Questo \u00e8 un altro comportamento che dovete conoscere. Se lo restituiamo, l'ID di transazione va via. Il 724 va via. Ma ora abbiamo il 725. <\/p>\n
<\/p>\n
E cosa sto cercando di fare qui? Sto cercando di mostrarvi esempi di blocchi insoliti che potete incontrare: che si tratti di blocchi serializzabili o SAVEPOINT - sono diversi tipi di blocchi che appariranno nella tabella dei blocchi. <\/p>\n
<\/p>\n
<\/p>\n
Questo \u00e8 il creare blocchi espliciti, che hanno pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
E vedete che il tipo di blocco \u00e8 elencato qui come advisory. E in rosso c'\u00e8 scritto 'advisory'. E potete bloccare simultaneamente con pg_advisory_unlock.<\/p>\n
<\/p>\n
<\/p>\n
E infine vorrei mostrarvi un'altra cosa sorprendente. Creer\u00f2 un altro tipo. Ma collegher\u00f2 la tabella pg_locks con la tabella pg_stat_activity. E perch\u00e9 voglio farlo? Perch\u00e9 questo mi permetter\u00e0 di vedere tutte le sessioni attuali e quali blocchi stanno aspettando. Ed \u00e8 piuttosto interessante, quando uniamo la tabella dei blocchi con 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 vedete qui adesso? Queste sono le query, cio\u00e8 vedete l'intero elenco delle query elencate nella colonna di sinistra. E poi, sul lato destro, potete vedere i blocchi e cosa stanno creando. E questo potrebbe risultarvi pi\u00f9 chiaro, in modo da non dover tornare ogni volta a ogni sessione per vedere se \u00e8 necessario unirsi o meno. Lo fa per noi. <\/p>\n
<\/p>\n
Un'altra funzionalit\u00e0 che \u00e8 molto utile \u00e8 pg_blocking_pids<\/code>. Probabilmente non ne hai mai sentito parlare. Cosa fa? Ci consente di dire quale ID processo 11740 sta aspettando per questa sessione. E puoi vedere che 11740 sta aspettando 724. E 724 \u00e8 in cima. Mentre 11306 \u00e8 il tuo ID processo. Fondamentalmente, questa funzione scorre la tua tabella di blocco. E so che \u00e8 un po' complicato, ma riesci a capirlo. Fondamentalmente, questa funzione percorre questa tabella di blocco e cerca il processo ID, considerando i blocchi che sta aspettando. Prova anche a calcolare quale processo ID ha il processo in attesa di blocco. Quindi puoi eseguire questa funzione. pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
E questo pu\u00f2 essere davvero utile. L'abbiamo aggiunto solo dalla versione 9.6, quindi questa funzione ha solo 5 anni, ma \u00e8 molto, molto utile. Lo stesso vale per la seconda richiesta. Mostra esattamente ci\u00f2 che abbiamo bisogno di vedere. <\/p>\n
<\/p>\n
<\/p>\n
\u00c8 di questo che volevo parlarvi. E come mi aspettavo, abbiamo utilizzato tutto il nostro tempo, perch\u00e9 c'era un numero cos\u00ec elevato di diapositive. Le diapositive sono disponibili per il download. Vorrei ringraziarvi per essere stati qui. Sono sicuro che vi piacer\u00e0 il resto della conferenza, grazie mille!<\/p>\n
<\/p>\n
Domande:<\/p>\n
<\/p>\n
Ad esempio, se sto cercando di aggiornare le righe e la seconda sessione sta cercando di eliminare l'intera tabella. Da quanto ho capito, ci dovrebbe essere qualcosa come un intent lock. Esiste qualcosa di simile in Postgres?<\/em><\/p>\n<\/p>\n
<\/p>\n
Torniamo all'inizio. Forse ricorderete che quando fate qualsiasi cosa, ad esempio quando eseguite un SELECT, rilasciamo un AccessShareLock. E questo impedisce l'eliminazione della tabella. Quindi, se ad esempio volete aggiornare una riga in una tabella o eliminare una riga, qualcun altro non pu\u00f2 eliminare l'intera tabella contemporaneamente, perch\u00e9 mantenete questo AccessShareLock su tutta la tabella e sulla riga. E una volta che avete finito, possono eliminarla. Ma finch\u00e9 state modificando qualcosa, non possono farlo.<\/p>\n
<\/p>\n
Facciamo un altro esempio. Passiamo a un esempio di eliminazione. E vedete come ci sia un lock esclusivo su tutta la tabella. <\/p>\n
<\/p>\n
Sar\u00e0 simile a un lock esclusivo, giusto?<\/em><\/p>\n<\/p>\n
S\u00ec, sembra cos\u00ec. Capisco cosa intendi. Stai dicendo che, se eseguo un SELECT, avr\u00f2 ShareExclusive, e poi lo trasformo in uno stato Row Exclusive, questo diventa un problema? Ma sorprendentemente non crea problemi. Sembra un aumento del livello di blocco, ma in effetti ho un lock che impedisce la cancellazione. E ora, quando faccio questo lock pi\u00f9 forte, continua a impedire la cancellazione. Quindi non \u00e8 un aumento. Cio\u00e8, impediva gi\u00e0 prima quando era a un livello inferiore, quindi, quando aumento il suo livello, continua a impedire la cancellazione della tabella. <\/p>\n
<\/p>\n
Capisco cosa intendi. Qui non c'\u00e8 un caso di aumento del livello di blocco, dove stai cercando di rinunciare a un lock per introdurne uno pi\u00f9 potente. Qui si tratta semplicemente di un aumento generale di questa prevenzione, quindi non causa alcun conflitto. Ma \u00e8 una bella domanda. Grazie mille per averla posta!<\/p>\n
<\/p>\n
Cosa dobbiamo fare per evitare la situazione di deadlock quando abbiamo molte sessioni e un grande numero di utenti?<\/em><\/p>\n<\/p>\n
Postgres rileva automaticamente situazioni di deadlock e rimuover\u00e0 automaticamente una delle sessioni. L'unico modo per evitare situazioni di deadlock \u00e8 bloccare le entit\u00e0 nello stesso ordine. Pertanto, quando esamini la tua applicazione, spesso la causa dei deadlock \u00e8... Immaginiamo che io voglia bloccare due cose diverse. Un'applicazione blocca la tabella 1, mentre un'altra blocca la tabella 2 e poi la tabella 1. Il modo pi\u00f9 semplice per evitare i deadlock \u00e8 assicurarti che il blocco avvenga sempre nello stesso ordine in tutte le applicazioni. Questo generalmente elimina l'80% dei problemi, poich\u00e9 diversi sviluppatori scrivono queste applicazioni. Se le blocchi nello stesso ordine, non ti troverai ad affrontare situazioni di deadlock.<\/p>\n
<\/p>\n
Grazie mille per il tuo intervento! Hai parlato di vacuum full e, se non sbaglio, vacuum full altera l'ordine delle righe in uno storage separato, quindi mantiene le righe esistenti inalterate. Ma perch\u00e9 vacuum full richiede un blocco 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, in sostanza, stiamo creando una nuova versione della tabella. La tabella sar\u00e0 nuova. Risulta che sar\u00e0 una versione completamente nuova della tabella. E il problema \u00e8 che, quando facciamo questo, non vogliamo che le persone la leggano, perch\u00e9 dobbiamo assicurarci che vedano la nuova tabella. E quindi questo si collega alla domanda precedente. Se potessimo leggere contemporaneamente, non saremmo in grado di spostarla e indirizzare le persone alla nuova tabella. Dovremmo attendere che tutti finissero di leggere questa tabella, quindi, in sostanza, si tratta di una situazione di lock esclusivo.
<\/p>\n
\u00c8 possibile aggiungere un tempo di attesa per il blocco in Postgres? In Oracle posso, ad esempio, scrivere \u201cseleziona per aggiornare\u201d e attendere 50 secondi per l'aggiornamento. Questo andava bene per l'applicazione. Ma in Postgres, o devo farlo subito e non aspettare affatto, oppure attendere fino a un certo tempo.<\/em> <\/p>\n<\/p>\n
S\u00ec, puoi selezionare un timeout per i tuoi blocchi. Puoi anche emettere il comando no way, che sar\u00e0... se non riesci a ottenere immediatamente il blocco. Quindi, o lock timeout, o qualcos'altro che ti permetter\u00e0 di farlo. Questo non si fa a livello sintattico. Si fa come variabile sul server. A volte non pu\u00f2 essere usato.<\/p>\n
<\/p>\n
Puoi aprire 75 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 703?<\/em><\/p>\n<\/p>\n
E questa \u00e8 una domanda interessante. Non capisco perch\u00e9 Postgres lo faccia. Quando 703 \u00e8 stato creato, si aspettava 702. E quando 704 e 705 appaiono, sembra che non sappiano cosa stanno aspettando, perch\u00e9 non c'\u00e8 ancora nulla. E Postgres agisce in questo modo: quando non riesci a ottenere un blocco, scrive \"Qual \u00e8 il senso di elaborarti?\", perch\u00e9 stai gi\u00e0 aspettando qualcuno. Quindi semplicemente lo lasciamo l\u00ec, non aggiorna affatto. Ma cosa \u00e8 successo qui? Non 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 in attesa. E poi aggiorniamole insieme. E indichiamo che entrambi aspettano. <\/p>\n
<\/p>\n
Non so perch\u00e9 Postgres si comporti in questo modo. Ma c'\u00e8 un problema chiamato f\u2026. Sembra che non sia un termine russo. \u00c8 quando tutti aspettano lo stesso lock, anche se ci sono 20 istanze che aspettano il lock. E all'improvviso si svegliano tutti insieme. E tutti iniziano a cercare di reagire. Ma il sistema fa in modo che tutti aspettino 703. Perch\u00e9 tutti stanno aspettando, e li metteremo immediatamente in coda. E se appare qualsiasi altra nuova richiesta, generata dopo questa, per esempio 707, ci sar\u00e0 di nuovo un vuoto. <\/p>\n
<\/p>\n
E penso che questo venga fatto per poter dire che in questa fase 702 sta aspettando 703, e tutti quelli che arriveranno dopo non avranno nessuna registrazione in questo campo. Ma appena il primo in attesa se ne va, tutti quelli che aspettavano in quel momento prima dell'aggiornamento ricevono lo stesso marker. E quindi, credo sia stato fatto per poter gestire in ordine, in modo che fossero correttamente ordinati. <\/p>\n
<\/p>\n
Ho sempre visto questo come un fenomeno piuttosto strano. Perch\u00e9 qui, ad esempio, non li elenchiamo affatto. Ma credo che ogni volta che diamo un nuovo blocco, guardiamo a tutti coloro che sono in attesa. Allora li mettiamo tutti in coda. E poi, qualsiasi nuovo arrivo viene messo in coda solo quando la persona successiva ha terminato di essere elaborata. Ottima domanda. Grazie mille per la domanda!<\/p>\n
<\/p>\n
Mi sembra molto pi\u00f9 logico quando il 705 attende il 704.<\/em> <\/p>\n<\/p>\n
Ma il problema \u00e8 il seguente. Tecnicamente puoi risvegliare l'uno o l'altro. E quindi risveglieremo quello o l'altro. Ma cosa succede nel funzionamento del sistema? Vedi come 703 in cima ha bloccato il proprio ID di transazione. Questo \u00e8 il modo in cui funziona Postgres. E 703 \u00e8 bloccato dal suo stesso ID di transazione, quindi, se qualcuno vuole aspettare, dovr\u00e0 aspettare 703. E, in sostanza, 703 si completa. Solo dopo il suo completamento, uno dei processi si risveglia. E non sappiamo quale sar\u00e0 esattamente questo processo. Poi elaboriamo gradualmente tutto. Ma non \u00e8 chiaro quale processo si risveglier\u00e0 per primo, perch\u00e9 potrebbe essere uno qualsiasi di questi processi. Fondamentalmente, avevamo uno scheduler che diceva che ora possiamo risvegliare uno qualsiasi di questi processi. Scegliamo semplicemente uno a caso. Pertanto, entrambi devono essere contrassegnati, perch\u00e9 possiamo risvegliare uno qualsiasi di essi. <\/p>\n
<\/p>\n
E il problema \u00e8 che abbiamo la CP-infinito. E quindi \u00e8 molto probabile che possiamo risvegliare quello pi\u00f9 tardi. E se, ad esempio, risvegliamo quello pi\u00f9 tardi, ci aspetteremo colui che ha appena ricevuto un blocco, quindi non definiamo chi sar\u00e0 risvegliato per primo. Creiamo semplicemente una situazione del genere e il sistema li risveglier\u00e0 in ordine casuale. <\/p>\n
<\/p>\n
S\u00ec articoli sui locks di Egor Rogov<\/a><\/noindex>. Guarda, sono anche interessanti e utili. L'argomento \u00e8, ovviamente, estremamente 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
![\"Sbloccare](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n