Re: freeze database durante creazione tabella o campo tabella

Si postgres è alla versione 8.4.4.
Non so se sia un rischio che si possa correrre fare un upgrade ma ne vaglieremo la possibilità..
ai lock ci avevo pensato, ma mi sorge un dubbio: le transazioni non sono migliaia e neanche centinaia in quel determinato istante, quindi se con la mia operazione di aggiornamento vorrei metter n lock, non dovrebbero esserci grossi problemi nel farlo in tempi accettabili in quanto la rtansazione dura qualche millisecondo.
io ed i miei colleghi abbiamo notato che se c sono connessioni in IDLE(noi dello staf che abbamo testato una servlet pe esempio) che sono effettivamente in idle il db freeza e necessita di un riavvio

----Messaggio originale----
Da: gabriele(dot)bartolini(at)2ndQuadrant(dot)it
Data: 18-nov-2012 11.14
A: <pgsql-it-generale(at)postgresql(dot)org>
Cc: "xian88(at)alice(dot)it"<xian88(at)alice(dot)it>
Ogg: Re: [pgsql-it-generale] freeze database durante creazione tabella o campo tabella

Ciao,

Il 17/11/12 09:36, xian88(at)alice(dot)it ha scritto:
> comporta un discreto numero di connessioni "attive" contemporaneamente (anche
> se in IDLE).
Suppongo sia un PostgreSQL < 9.2, ma che versione?

> Difatto non
> capendo il reale motivo di questo strano comportamento, si è notato comunque
> che dopo il necessario riavvio del servizio postgres a connessioni
> zero sul DB
> queste operazioni di modifica dello schema non provacano nessun effetto
> collaterale.
Non è proprio strano come comportamento. Tentanto di modificare la
struttura di una tabella, quella transazione tenta di acquisire un lock
esclusivo su tutta la tabella, andando a influenzare le transazioni
attive che hanno fatto (o faranno) uso di quella tabella. Inoltre, anche
l'aggiunta di un campo a una tabella, a seconda della versione di
Postgres, può portare a una riscrittura completa di tutta la tabella.

È ovvio che sto ragionando soltanto in termini generali, non avendo dati
concreti sui quali investigare.

Ad ogni modo le consiglio due cose:

* esaminare, prima di attivare la modalità Windows anche a Postgres
(ovvero reboot), la vista pg_locks
* valutare di partecipare al PGDay di venerdì prossimo, 23 novembre
(www.pgday.it) in quanto ci saranno due talk su monitoraggio e analisi
dei log

A presto,
Gabriele

--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gabriele(dot)bartolini(at)2ndQuadrant(dot)it | www.2ndQuadrant.it

studiando un po' il problema e parlando con i miei colleghi, stiamo vagliando una soluzione al problema.
il database in questione purtroppo è disordinato e male organizzato in alcune parti.
una di queste sono i tablespace. vorrei chiederVi se spostare trigger, role e indici potrebbe un po arginare il problema, almeno per quanto riguarda l'attivazione/disattivazione di essi o l'aggiunta di nuovi

> Si postgres è alla versione 8.4.4.
> Non so se sia un rischio che si possa correrre fare un upgrade ma ne vaglieremo la possibilità..
> ai lock ci avevo pensato, ma mi sorge un dubbio: le transazioni non sono migliaia e neanche centinaia in quel determinato istante, quindi se con la mia operazione di aggiornamento vorrei metter n lock, non dovrebbero esserci grossi problemi nel farlo in tempi accettabili in quanto la rtansazione dura qualche millisecondo.
> io ed i miei colleghi abbiamo notato che se c sono connessioni in IDLE(noi dello staf che abbamo testato una servlet pe esempio) che sono effettivamente in idle il db freeza e necessita di un riavvio
>
>
>
>
> ----Messaggio originale----
> Da: gabriele(dot)bartolini(at)2ndQuadrant(dot)it
> Data: 18-nov-2012 11.14
> A: <pgsql-it-generale(at)postgresql(dot)org>
> Cc: "xian88(at)alice(dot)it"<xian88(at)alice(dot)it>
> Ogg: Re: [pgsql-it-generale] freeze database durante creazione tabella o campo tabella
>
> Ciao,
>
> Il 17/11/12 09:36, xian88(at)alice(dot)it ha scritto:
> > comporta un discreto numero di connessioni "attive" contemporaneamente (anche
> > se in IDLE).
> Suppongo sia un PostgreSQL < 9.2, ma che versione?
>
> > Difatto non
> > capendo il reale motivo di questo strano comportamento, si è notato comunque
> > che dopo il necessario riavvio del servizio postgres a connessioni
> > zero sul DB
> > queste operazioni di modifica dello schema non provacano nessun effetto
> > collaterale.
> Non è proprio strano come comportamento. Tentanto di modificare la
> struttura di una tabella, quella transazione tenta di acquisire un lock
> esclusivo su tutta la tabella, andando a influenzare le transazioni
> attive che hanno fatto (o faranno) uso di quella tabella. Inoltre, anche
> l'aggiunta di un campo a una tabella, a seconda della versione di
> Postgres, può portare a una riscrittura completa di tutta la tabella.
>
> È ovvio che sto ragionando soltanto in termini generali, non avendo dati
> concreti sui quali investigare.
>
> Ad ogni modo le consiglio due cose:
>
> * esaminare, prima di attivare la modalità Windows anche a Postgres
> (ovvero reboot), la vista pg_locks
> * valutare di partecipare al PGDay di venerdì prossimo, 23 novembre
> (www.pgday.it) in quanto ci saranno due talk su monitoraggio e analisi
> dei log
>
> A presto,
> Gabriele
>
> --
> Gabriele Bartolini - 2ndQuadrant Italia
> PostgreSQL Training, Services and Support
> gabriele(dot)bartolini(at)2ndQuadrant(dot)it | www.2ndQuadrant.it