Gracias Gerardo / Hellmuth, efectivamente, tenia una conexión en "idle
in transaction" desde hacia un me, al matarla y volver con el vacuum
manual (el full) todo volvió a la normalidad.
On 2017-06-05 10:18, Hellmuth Vargas wrote:
Hola Diego
En primer lugar, esto sucede porque
- autovacuum in
Hola Diego
En primer lugar, esto sucede porque
- autovacuum inactivo
- no tenga programado tareas de mantenimiento diarias con VACUUM ó
*- Exista una transacción antigua, sin resolver, que no ha permitido la
ejecución del mantenimiento respectivo.*
Ahora bien, porque la tabla presenta este tam
- Mensaje original -
> De: "Diego"
> Para: pgsql-es-ayuda@postgresql.org
> Enviados: Lunes, 5 de Junio 2017 8:43:18
> Asunto: [pgsql-es-ayuda] Vacuum
>
> Buenos días Postgresistas,
>
> Hoy les escribo para consultarles sobre una situación que me pasa con
> una tabla.
> Esta tabla tiene
...@systemguards.com.ec [mailto:jcasa...@systemguards.com.ec] En
nombre de Jaime Casanova
Enviado el: sábado, 27 de abril de 2013 23:16
Para: Fernando Hevia
CC: Mario Alberto Soto Cordones; Ayuda; pgsql-es-ayuda-ow...@postgresql.org
Asunto: Re: [pgsql-es-ayuda] Vacuum a una tablas
2013/4/27 Fernando Hevia
2013/4/27 Fernando Hevia :
>
> Si se puede ejecutar vacuum en una función. Sería un buen comienzo que
> postees el comando tal cual lo ejecutas y el error que arroja.
>
no, no se puede
Mira las notas en http://www.postgresql.org/docs/9.2/static/sql-vacuum.html
"""
VACUUM cannot be executed inside
5 at EXECUTE statement
NOTICE: FALLO PROCESO :: cannot begin/end transactions in PL/pgSQL
ERROR: cannot begin/end transactions in PL/pgSQL
HINT: Use a BEGIN block with an EXCEPTION clause instead.
CONTEXT: PL/pgSQL function "respalda_msj" line 52 at SQL statement
**
2013/4/27 Mario Alberto Soto Cordones
> ** **
>
> Hola Lista:
>
> ** **
>
> Estoy tratando de hacer un vacuum a una tabla cuyo nombre se pasa por
> parámetro dentro de un script o una unción, en ninguno de los 2 casos me
> funciona, solo me funciona el vacuumdb, pero eso no es lo que quiero**
Alvaro, ok gracias
saludos
eduardo
2012/11/27 Alvaro Herrera
> Eduardo Arenas C. escribió:
> > Alvaro, En el caso de generar indices que sería lo recomendable, re
> > generarlos antes del VACUUM FREEZE ANALYZE, o despues de ese paso?
>
> Si los vas a borrar, hazlo antes de la eliminación masi
Eduardo Arenas C. escribió:
> Alvaro, En el caso de generar indices que sería lo recomendable, re
> generarlos antes del VACUUM FREEZE ANALYZE, o despues de ese paso?
Si los vas a borrar, hazlo antes de la eliminación masiva y agrégalos
después que todo está listo.
--
Álvaro Herrera
Alvaro, En el caso de generar indices que sería lo recomendable, re
generarlos antes del VACUUM FREEZE ANALYZE, o despues de ese paso?
Saludos y Gracias
Eduardo.
2012/11/22 Alvaro Herrera
> Sergio Valdes Hurtado escribió:
> > Una cosa importante que me olvidé de mencionar, es que esta base de
Sergio Valdes Hurtado escribió:
> Una cosa importante que me olvidé de mencionar, es que esta base de datos
> es una epecie de data warehouse y estas cargas masivas de datos son las
> únicas transacciones que agregan o quitan data, todo lo demas son consultas
> de selección.
Yo haría algo así:
DE
Una cosa importante que me olvidé de mencionar, es que esta base de datos
es una epecie de data warehouse y estas cargas masivas de datos son las
únicas transacciones que agregan o quitan data, todo lo demas son consultas
de selección.
El 22 de noviembre de 2012 11:46, Lazaro Ruben Garcia Martin
Para el analyze automático, puedes revisar los siguientes parámetros de
configuración, además autovacuum debe estar en on.
Saludos.
- Mensaje original -
> El autovacuum esta activado, pero no realizo analyze.
> Además ejecuto un vacuum manualmente despues del proceso de carga, ya
> que
El autovacuum esta activado, pero no realizo analyze.
Además ejecuto un vacuum manualmente despues del proceso de carga, ya que
en algunas tablas se eliminan y graban alrededor de 3 millones de registros.
Saludos
El 22 de noviembre de 2012 10:44, Lazaro Ruben Garcia Martinez <
lgarc...@uci.cu> es
Ten en cuenta que cuando borrasun voluen alto de data el indice puede sufrir de
bloat. En esta pagina hay uaconsulta para ver los objetos con bloat
http://wiki.postgresql.org/wiki/Show_database_bloat si el indice esta en la
lsita entonces realiza un reindex
--- On Thu, 11/22/12, Sergio Valdes H
Y con que frecuencia realizas vacuum y analyze?
Ten en cuenta que realizar analyze permitirá actualizar los planes de ejecución
de la base de datos y mediante vacuum eliminas las tuplas muertas, disminuyendo
espacio en disco y mejorando el rendimiento.
Yo particularmente tengo el autovacuum del
Excerpts from Marcos Ortiz's message of mar sep 11 11:19:47 -0300 2012:
> Bueno, mi recomendación es que actualices tu PostgreSQL. Ayer mismo
> salió la 9.2, por lo que si no me equivoco, ya se le debe haber quitado
> el soporte a la versión 8.2.
8.2 dejó de tener soporte en diciembre pasado. E
Excerpts from viart's message of mar sep 11 09:05:57 -0300 2012:
> Buenos días a todos,
>
> Estoy ejecutando un [ vacuumdb --analyze --table "\"ARQ076"\" SBU ] desde
> la consola del servidor Linux, donde está instalado el Postgres 8.2, pero
> cuando acaba el vacuum, consulto la tabla por Pg
aun me parece raro que se
actualicen al momento.
saludos,
Antonio Salas Mena
De: Marcos Ortiz [mailto:mlor...@uci.cu]
Enviado el: martes, 11 de septiembre de 2012 16:20
Para: viart
CC: 'Lista PostgreSQL en Español'
Asunto: Re: [pgsql-es-ayuda] Vacuum analize no actualiz
Bueno, mi recomendación es que actualices tu PostgreSQL. Ayer mismo
salió la 9.2, por lo que si no me equivoco, ya se le debe haber quitado
el soporte a
la versión 8.2.
Ahora, con relación a tu problema, ¿Qué versión de PgAdmin estás usando?
On 09/11/2012 08:05 AM, viart wrote:
Buenos días a to
On 08/10/2011 06:29 PM, Julio Cesar Ayala Guarin wrote:
madrugada después de la carga de las novedades a la bd de contingencia
se ejecuta vacuumdb --analyze -a
Esto solamente ejecuta ANALYZE para actualizar las estadisticas usadas
por el planner
Versión de Postgres --> 8.4.1
Actualiza al men
PostgreSQL
*-www.jqmicrosistemas.com
*-809-849-8087
*---*
> Date: Thu, 26 May 2011 16:47:47 -0300
> From: msile...@easymail.net.ar
> To: alvhe...@alvh.no-ip.org
> CC: pgsql-es-ayuda@postgresql.org
> Subject: Re: [pgsql-e
Excerpts from Mario Sileone's message of vie may 27 15:43:01 -0400 2011:
> La verdad no he encontrado la manera con los parámetros que vi del
> autovacuum , como sería eso? me interesa muchisimo saberlo.
insert into pg_autovacuum values ('tu_tabla'::regclass, false, -1, -1, ...)
(completar con -
La verdad no he encontrado la manera con los parámetros que vi del
autovacuum , como sería eso? me interesa muchisimo saberlo.
Gracias de Antemano
El 27/05/2011 16:28, Alvaro Herrera escribió:
Excerpts from Mario Sileone's message of vie may 27 15:17:53 -0400 2011:
> Es correcto, lo que suce
Excerpts from Mario Sileone's message of vie may 27 15:17:53 -0400 2011:
> Es correcto, lo que sucede es que, tenemos tablas muy grandes con split,
> por lo que evito usar el autovacuum, ya que no puedo omitir estas tablas
> (que tienen solo inserts) pero juntan mensualmente cerca de 20 millones
Excerpts from Edwin Quijada's message of vie may 27 15:05:49 -0400 2011:
>
> Una pregunta...No se suppone que autovacuum eliminaria la necesidad de este
> vacuum. Lo digo porque he cambiado todo eso y ya no lo usoHay que seguir
> usando vacuum ?
No es obligatorio. Si no quieres usar autovacuum
Es correcto, lo que sucede es que, tenemos tablas muy grandes con split,
por lo que evito usar el autovacuum, ya que no puedo omitir estas tablas
(que tienen solo inserts) pero juntan mensualmente cerca de 20 millones
de registros.
Saludos.
El 27/05/2011 16:05, Edwin Quijada escribió:
elimin
Clarísimo, muchas gracias!.
El 26/05/2011 16:45, Alvaro Herrera escribió:
Esta parte es de analyze, y corresponde a la muestra aleatoria de
páginas que se recorren para obtener estadísticas. No tiene nada que
ver con las páginas que vacuum necesita para limpiar la
-
Enviado a la lista de corre
Excerpts from Mario Sileone's message of jue may 26 15:10:04 -0400 2011:
> Estimada lista, tengo una consulta con respecto al vacuum.
> resulta que todos los dias, hacemos un vacuum a toda la base de datos
> para evitar el wraparound, pero generalmente, hacemos en forma manual
> también algunos v
Excerpts from Ariel Centeno's message of mar abr 05 14:30:11 -0300 2011:
>
> Estamos teniendo problemas con el vacuum y nos esta obligando a cambiar el
> valor de «max_fsm_pages» muy seguido queriamos saber si hay alguna manera de
> mantenerlo mas bajo y tambien en una base mediana que valor ten
El mar, 05-04-2011 a las 17:30 +, Ariel Centeno escribió:
> Estamos teniendo problemas con el vacuum y nos esta obligando a
> cambiar el valor de «max_fsm_pages» muy seguido queriamos saber si hay
> alguna manera de mantenerlo mas bajo y tambien en una base mediana que
> valor tendria que ser
Miguel,
Yo empezaria viendo si tenes algun lock que este atascando el proceso de vacuum.
Podes hacerlo con un "ps -fu postgres | grep waiting " desde el shell
del servidor ( esto si no estas en windows ). Si en el resultado
aparece el proceso vacuum, hay un lockeo que hay que estudiar
La otra form
ok toncs ntiendo k lo que estoy haciendo es correcto solo
que tengo que ser paciente
*y porque los bloqueaste? vacuum es inofensivo y no afecta a las demas
operaciones de la bd... pueden haber escrituras y lecturas
concurrentemente con el vacuum
*
porque yo en una hora consumo 1 millon de transacc
2010/12/14 Miguel Angel Hernandez Moreno :
> ok aparentemento todo va bien
>
> solo para confirmar:
>
> el vacuum era solo "vacuum a secas" que puedo ejecutar desde pgadmin
>
si
> cuando acabe el vacuum ya no hay nada mas que hacer, solo vuelvo a
> permitir los accesos de lectura y escritua de l
ok aparentemento todo va bien
solo para confirmar:
el vacuum era solo "vacuum a secas" que puedo ejecutar desde pgadmin
cuando acabe el vacuum ya no hay nada mas que hacer, solo vuelvo a
permitir los accesos de lectura y escritua de la bd
y si ya el vacuum se esta haciendo a las tablas y ya no
2010/12/14 Miguel Angel Hernandez Moreno :
>
> Otra cosa que tienes que fijarte es si el vacuum de alguna tabla está
> muriendo con un error.
> donde puedo fijarme
>
en los logs
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
-
Enviado
*Quizás podrías rebajar el autovacuum_vacuum_cost_delay a 10 o menos.
*con eso se tiene alguna idea de cuanto se tardaria si mi bd comprimida
pesa alrededor de medio tera
*Otra cosa que tienes que fijarte es si el vacuum de alguna tabla está
muriendo con un error.*
donde puedo fijarme
El 14 de di
Excerpts from Miguel Angel Hernandez Moreno's message of mar dic 14 12:30:01
-0300 2010:
> oye tengo en vacuum parado,
> hay un "autovacuum worker process"
> que tiene el vacuum en "waiting"
Seguramente quiere procesar una tabla que el otro está procesando. Sólo
puede haber un vacuum sobre una m
oye tengo en vacuum parado,
hay un "autovacuum worker process"
que tiene el vacuum en "waiting"
que puedo hacer para darle mayor velocidad a esto
El 14 de diciembre de 2010 08:10, Jaime Casanova
escribió:
> 2010/12/14 Miguel Angel Hernandez Moreno :
> > hola, disculpa y entoncses
> >
> > ya esta
2010/12/14 Miguel Angel Hernandez Moreno :
> hola, disculpa y entoncses
>
> ya esta corriendo el vacuum desde lo que es pgagmin
> mi duda es si este vacuum se hace solo a los catalogos
> o a los catalogos y a las tablas??
>
si estas conectado como el usuario postgres (o algun otro
superusuario) y
hola, disculpa y entoncses
ya esta corriendo el vacuum desde lo que es pgagmin
mi duda es si este vacuum se hace solo a los catalogos
o a los catalogos y a las tablas??
El 14 de diciembre de 2010 01:15, Miguel Angel Hernandez Moreno <
miguel.hdz@gmail.com> escribió:
> como efectuo el vacuum?
como efectuo el vacuum??
por termina?? que sentencia se pondria en terminal??
o desde pgpadmin, "click derecho" y mantenimientos>>vacuum
El 13 de diciembre de 2010 23:54, Jaime Casanova
escribió:
> 2010/12/14 Miguel Angel Hernandez Moreno :
> > hay algun riesgo de que pierda mi informacion al
2010/12/14 Miguel Angel Hernandez Moreno :
> hay algun riesgo de que pierda mi informacion al hacer el vacuum??
>
nunca entenderé esta pregunta... que sentido tendría que la base te
exija realizar una operación potencialmente peligrosa?
mas bien, tienes riesgo de perder tu información si no ejecu
hay algun riesgo de que pierda mi informacion al hacer el vacuum??
El 13 de diciembre de 2010 22:35, Jaime Casanova
escribió:
> 2010/12/13 Miguel Angel Hernandez Moreno :
> >
> > WARNING: database "feria" must be vacuumed within 8213017 transactions
> >
> > me marca ese WARNING, si hiciera un pg
2010/12/13 Miguel Angel Hernandez Moreno :
>
> WARNING: database "feria" must be vacuumed within 8213017 transactions
>
> me marca ese WARNING, si hiciera un pg_dump afectaria en las transaciones,
> podria perder el respaldo si se llegasen a cumplir las transaciones limite??
>
pg_dump abre una tr
2010/2/9 Andrés P.P. :
>
> Jaime
>
> El autovacuum está en off desde un principio.
>
[...]
> Cuándo dices "catalogos del sistema" te refieres a los particulares que usa
> la aplicación??o a aquellos que son de tipo administrativo del motor
> postgres? En los de la aplicación sólo
Jaime
El autovacuum está en off desde un principio.la carga es tan pequeña
y "específica", por decirlo de alguna forma, que se decidió que se hicieran
vacuums en estas cargas que se daban cada 10 minutos ya que era el momento
en el que se limpiaban dos tablas y se generaban updates en
otra
2010/2/8 Andrés P.P. :
>
> Tengo una BD pequeña en la cual hay 4 tablas que tiene actividad cada 10
> minutos que incluyen update y delete y en las cuales se ejecuta un vacuum en
> cada uno de esos ciclos (10 minutos) no ha sido necesario configurar un
> autovacuum ya que el nivel de carga es b
Andrés P.P. escribió:
> Por lo anterior había pensando en que era factible usar el vacuum
> analyze. ya que haciéndolo en el momento justo no creo que afecte en
> otras areas... pero es mejor asegurarse, asi que seguiré tu consejo.
De ser factible, es factible.
--
Alvaro Herrera V
Ahh..ok!..
Te pregunté esa diferencia de curioso ya que la BD es realmente pequeña y la
mayor actividad se reduce justamente a estos ciclos de carga que se dan cada
10 minutos... y cada procesamiento no supera los 10 o 30 segundos (entre
truncar las tablas, cargar las tablas con data nueva y ejecu
Andrés P.P. escribió:
> después de limpiar la pg_statistics ejecuto el analyze sólo?.. qué
> diferencia hay entre un "analyze" y un "vacuum analyze" para esta situación
> particular (de puro curioso no más pregunto esto...).
La diferencia es que VACUUM ANALYZE va a hacer un vacuum de cada tabla,
Marcos
Lo de hacer el ciclo del vacuum cada 10 minutos es que estos Vacuum están en
un script que se ejecuta via crontab y están asociados a 2 tablas que se
vacían (truncate) completamente y luego se cargan con archivos que la
aplicación va dejando cada 10 minutos. en ese sentido no sé
> Tengo una BD pequeña en la cual hay 4 tablas que tiene actividad cada 10
> minutos que incluyen update y delete y en las cuales se ejecuta un vacuum en
> cada uno de esos ciclos (10 minutos) no ha sido necesario configurar un
> autovacuum ya que el nivel de carga es bajo.
¿Qué versión de pos
El 08/02/2010 21:08, Andrés P.P. escribió:
Hola!
Perdonen lo extenso..Creo tener la solución al siguiente problema pero
lo quiero validar con Uds. antes de aplicarlo.
Tengo una BD pequeña en la cual hay 4 tablas que tiene actividad cada
10 minutos que incluyen update y delete y en las cuales se
- Original Message -
From: "Jaime Casanova"
To: "Mario Sileone"
Cc: "Alvaro Herrera" ;
Sent: Thursday, February 04, 2010 12:26 PM
Subject: Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas.
2010/2/4 Mario Sileone :
Lo que quiero lo
2010/2/4 Mario Sileone :
>
> Lo que quiero lograr es, con una regla similar a la de INSERTS, que los
> selects vayan directamente a las tablas heredadas que corresponden, sin
> pasar por todas.
>
> Ejemplo: si realizo una consulta de reportes desde el 10 de diciembre del
> 2009 al 2 de enero de
- Original Message -
From: "Jaime Casanova"
To: "Mario Sileone"
Cc: "Alvaro Herrera" ;
Sent: Thursday, February 04, 2010 11:56 AM
Subject: Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas heredadas.
2010/2/4 Mario Sileone :
Con respecto a
2010/2/4 Mario Sileone :
> Con respecto a las rules con selects hay una manera genérica de desviar solo
> el nombre de la tabla o se debe definir cada consulta que se realiza en el
> DO INSTEAD ?
> Si tengo 3 consultas diferentes, debo realizar reglas para cada una de
> ellas?
>
que es lo que quie
diferentes, debo realizar reglas para cada una de
ellas?
Desde ya muchas gracias por todo.
- Original Message -
From: "Alvaro Herrera"
To: "Mario Sileone"
Cc:
Sent: Wednesday, February 03, 2010 4:35 PM
Subject: Re: [pgsql-es-ayuda] Vacuum, rules y Selects en tablas
Mario Sileone escribió:
> La consulta es la siguiente: Temiendo el famoso wraparound de los 2
> billones de transacciones que nos ha sucedido una vez, queríamos tener la
> posibilidad de hacer un vacuum full a toda la base de datos durante
> producción, y al tener tablas separadas por meses
2010/1/30 Sergio Gabriel Rodriguez :
> Hola lista;
> tengo la siguiente duda, ejecuto un vacuum analyze todas las noches sobre
> una base de datos de unos 120 GB aprox. el cual tarda casi 6 hs, he tocado y
necesitas hacer el vacuum de la base de datos todas las noches? porque
no dejas que autovacu
Gabriel Ferro escribió:
>
> Postgrerianos, he realizado un vacuum verbose analyze y al terminar me da
> el espacio libre contiene 587131 paginas en 30 relaciones ...
> 560960 entradas de pagina son necesarias pra registrar todo el espacio libre
> los limites actuales son 2159795 entradas de
62 matches
Mail list logo
