PostgreSQL si lamenta della memoria condivisa, ma la memoria condivisa sembra essere OK

Sto eseguendo una sorta di intensivo rilascio e creazione di schemi su un server PostgreSQL, ma ora mi lamento ..:

WARNING:  out of shared memory
ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.

Ma il problema persiste se PostgreSQL viene appena riavviato service postgresql restart, sospetto che max_locks_per_transaction non ottimizzerà nulla.

Sono un po 'estraneo perché gli elenchi di risoluzione dei problemi per questo errore non funzionano per me.

ULTERIORI INFORMAZIONI 1409291350: Mancano alcuni dettagli ma mantengo il risultato SQL di base.

postgres=# SELECT version();
PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2,
 64-bit

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:        14.04
Codename:       trusty

postgresql schema memory

— 48347
fonte

Versione PostgreSQL da SELECT version()? Problema interessante ...

— Craig Ringer,

"Sospetto che max_locks_per_transaction non metterà a punto nulla." - Perché lo sospetti? Hai provato a seguire il suggerimento del suggerimento?

— Josh Kupershmidt,

Hai provato a seguire il suggerimento del suggerimento? max_locks_per_transaction = 64 # min 10Finora ho commentato in /etc/postgresql/9.3/main/postgresql.conf.

— 48347

Il valore predefinito max_locks_per_transaction è 64 per cominciare - il commento alla riga non lo ha effettivamente modificato.

— yieldsfalsehood

OK un aumento effettivo a 128 ha risolto il problema , in realtà ha permesso all'operazione di continuare.

— 48347

Il tuo commento sull'abbandono e la creazione intensivi e l'avviso ricevuto in merito all'aumento di max_locks_per_transaction suggeriscono che stai abbandonando e creando molti oggetti nella stessa transazione . Ognuno di questi comporta un blocco, che richiede ciascuno una piccola quantità di memoria condivisa. Per questo motivo, max_locks_per_transaction limita il numero di blocchi che è possibile conservare all'interno di una transazione (per impedire a qualsiasi transazione di utilizzare tutta la memoria condivisa).

Potresti aumentare un po 'quel limite (ti consiglierei di non impostarlo arbitrariamente grande o ti imbatterai in una situazione separata di esaurire effettivamente la memoria condivisa totale) o fare i tuoi drop e crea in batch di transazioni o come un drop / crea per transazione.

Modifica: apparentemente mi sbagliavo su come funziona max_locks_per_transaction. Dalla documentazione, il numero totale di blocchi disponibili è max_locks_per_transaction * (max_connections + max_prepared_transactions) - ogni transazione può contenere più di max_locks_per_transaction, purché il numero di blocchi detenuti ovunque sia inferiore a questo valore totale.

— yieldsfalsehood
fonte

Il mio flusso di lavoro include (1) il dumping di uno schema X, (2) il rilascio di un altro schema Y e (3) il ripristino di X sul nome dello schema Y. Come ho detto, fino ad oggi ho passato diverse settimane a svolgere queste attività, e oggi il passaggio (2) non riesce. Il passaggio (2) consiste principalmente in DROP SCHEMA IF EXISTS public CASCADE; CREATE SCHEMA public, queste sono le frasi che generano AVVISO, ERRORE e SUGGERIMENTO.

— 48347

Il raddoppio dei blocchi massimi da 64 a 128 ha permesso al flusso di lavoro di continuare. Iv non ha ancora tutti gli interni, ma immagino che impegnarsi tra le frasi DROP SCHEMA e CREATE SCHEMA avrà un effetto di sollievo simile.

— 48347

Ora mi rendo conto che molti giorni ottengo un piccolo aumento dello schema e questo problema corrisponde perfettamente a uno di quei piccoli aumenti dello schema . Come strategia generale avrò maggiore attenzione con i SUGGERIMENTI d'ora in poi.

— 48347