Hola Alvaro
Muchas gracias por la respuesta... Finalmente, todas las réplicas que
tenía configurados slot y hot_standby_feedback en ON hacían que sus
correspondientes máster quedarán haciendo autovacuum "permanentementes" por
lo tanto se estableció hot_standby_feedback en OFF y se soluciono el t
Hellmuth Vargas escribió:
> Hola Alvaro
>
> Hice lo que sumrece me indico:
>
> - Borre el replication Slot
> - Comentarie # primary_slot_name = 'replica_local_slot' del archivo
> recovery.conf en la replica y reinicie la misma para que tomara el cambio
> - Realice un vacuum sobre la tabla marcad
Hola Alvaro
Hice lo que sumrece me indico:
- Borre el replication Slot
- Comentarie # primary_slot_name = 'replica_local_slot' del archivo
recovery.conf en la replica y reinicie la misma para que tomara el cambio
- Realice un vacuum sobre la tabla marcador
INFO: vacuuming "sac.marcador"
INFO:
Hellmuth Vargas escribió:
> Hola Alvaro
>
> No se si se me cruzaron las terminales!! reenvio todas las consultas y/o
> pantallas para verificar y si el es caso mil disculpas:
OK. Así tiene que haber sido ... los datos que das ahora son
diferentes. Lo importante considerar es acá:
> [postgres@M
Hola Alvaro
No se si se me cruzaron las terminales!! reenvio todas las consultas y/o
pantallas para verificar y si el es caso mil disculpas:
El servidor, por mantenimiento de la virtualizacion, se le realizo un
reinicio anoche (hacia las 9 pm), pero apenas inicio nuevamente las tablas
en mención
Hellmuth Vargas escribió:
> > Ahh, ¿no tendrás un standby con "feedback" activado que tiene una
> > transacción preparada, o un slot inactivo? Pega acá
> > select * from pg_stat_replication
>
>
> bd=# select * from pg_stat_replication
> bd-# ;
> -[ RECORD 1 ]+--
Hola Alvaro
El 3 de octubre de 2016, 16:39, Alvaro Herrera
escribió:
> Hellmuth Vargas escribió:
> > El 3 de octubre de 2016, 16:17, Alvaro Herrera
> > escribió:
> >
> > > Hellmuth Vargas escribió:
> > > > Hola Alvaro
> > > >
> > > > Muchas gracias por el tiempo.. respondo entre lineas:
> > >
> >
Hellmuth Vargas escribió:
> El 3 de octubre de 2016, 16:17, Alvaro Herrera
> escribió:
>
> > Hellmuth Vargas escribió:
> > > Hola Alvaro
> > >
> > > Muchas gracias por el tiempo.. respondo entre lineas:
> >
> > Pero no respondiste esta parte:
> >
> >¿no tendrás alguna transacción preparada abi
El 3 de octubre de 2016, 16:17, Alvaro Herrera
escribió:
> Hellmuth Vargas escribió:
> > Hola Alvaro
> >
> > Muchas gracias por el tiempo.. respondo entre lineas:
>
> Pero no respondiste esta parte:
>
>¿no tendrás alguna transacción preparada abierta? Mira en
>pg_stat_activity y pg_prepar
Hellmuth Vargas escribió:
> Hola Alvaro
>
> Muchas gracias por el tiempo.. respondo entre lineas:
Pero no respondiste esta parte:
¿no tendrás alguna transacción preparada abierta? Mira en
pg_stat_activity y pg_prepared_xacts.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Hola Alvaro
Muchas gracias por el tiempo.. respondo entre lineas:
El 3 de octubre de 2016, 16:01, Alvaro Herrera
escribió:
> Hellmuth Vargas escribió:
>
> > bd=# select * from pg_stat_user_tables where relname in ('marcador',
> > 'usuario');
>
> Por alguna razón estas tablas tienen n_dead_tup
Hellmuth Vargas escribió:
> bd=# select * from pg_stat_user_tables where relname in ('marcador',
> 'usuario');
Por alguna razón estas tablas tienen n_dead_tup que no parece decrecer?
¿no tendrás alguna transacción preparada abierta? Mira en
pg_stat_activity y pg_prepared_xacts.
Si haces un "va
Hola Alvaro
Respondo entre lineas
El 3 de octubre de 2016, 15:15, Alvaro Herrera
escribió:
> Hellmuth Vargas escribió:
> > Hola Alvaro, gracias por responder
> >
> > La versión anterior era la postgresql-9.3.12 pero incluso esta base de
> > datos la venia actualizando periódicamente con las dif
Hellmuth Vargas escribió:
> Hola Alvaro, gracias por responder
>
> La versión anterior era la postgresql-9.3.12 pero incluso esta base de
> datos la venia actualizando periódicamente con las diferentes publicaciones
> de la 9.3 y nunca observe el comportamiento que he descrito.
OK. ¿hay algún pa
Hola Alvaro, gracias por responder
La versión anterior era la postgresql-9.3.12 pero incluso esta base de
datos la venia actualizando periódicamente con las diferentes publicaciones
de la 9.3 y nunca observe el comportamiento que he descrito. El volcado del
control file es:
[postgres@M_BD tmp]#
Hellmuth Vargas escribió:
> Hola Franciso
>
> Si en efecto esta consumiendo mas recursos y la carga en general de la
> maquina ha subido en comparación con los valores que mantenía (estadísticas
> SAR) ademas, pues las operaciones que hacia antes son exactamente las
> mismas que esta haciendo aho
Hola Franciso
Si en efecto esta consumiendo mas recursos y la carga en general de la
maquina ha subido en comparación con los valores que mantenía (estadísticas
SAR) ademas, pues las operaciones que hacia antes son exactamente las
mismas que esta haciendo ahora por que no cambio en nada las aplic
Hellmuth:
2016-10-03 15:21 GMT+02:00 Hellmuth Vargas :
...
> inhabilito, pero ahora prácticamente se mantiene realizaron autovacuum a
> unas tablas de forma casi permanente, tema que no sucedía antes. Ya les
...
Independientemente de que este muchos mas tiempo corriendo el
autovacuum, ¿ consume m
Hola LIsta
El jueves pasado migre una base de datos importante con gran cantidad de
usuarios y aplicaciones concurrentes de la versión 9.3 a la 9.5 y me he
encontrado con un aumento significativo (excesivo) de operaciones de
autovacuum que no se evidenciaba en la versión 9.3. Las aplicaciones y
Brian Colman escribió:
> Buenos dias lista,
>
> Tengo una duda, tienen idea si los procesos autovacuum abiertos influyen en
> la cantidad de conexiones,
No cuentan contra el límite max_connections.
> la pregunta va porque para monitorear la base de
> datos utilizo un pluggin de Nagios (check_pos
Buenos dias lista,
Tengo una duda, tienen idea si los procesos autovacuum abiertos influyen en
la cantidad de conexiones, la pregunta va porque para monitorear la base de
datos utilizo un pluggin de Nagios (check_postgres), segun el ya llego al
maximo de conexiones, pero la base de datos sigue ace
: [email protected]
[mailto:[email protected]] En nombre de Espartano
Enviado el: miércoles, 30 de noviembre de 2011 01:13
Para: Lista PostgreSQL
Asunto: [pgsql-es-ayuda] Autovacuum en una sola db con multiples esquemas.
Hola gente, tengo una duda con el
Excerpts from Espartano's message of mié nov 30 02:42:58 -0300 2011:
> Hola gente, tengo una duda con el autovacuum, tengo una base de datos
> que tiene varios esquemas dentro de ella, cada esquema tiene un
> usuario mediante el cual se conectan unas aplicaciones que hacen
> repetidamente update s
Hola gente, tengo una duda con el autovacuum, tengo una base de datos
que tiene varios esquemas dentro de ella, cada esquema tiene un
usuario mediante el cual se conectan unas aplicaciones que hacen
repetidamente update sobre una tabla, esos programas realizan
periódicamente vacuum full (el nivel d
2011/4/15 Miguel Angel Hernandez Moreno :
> Saludos lista
>
> hace poco actualiza un servidor en postgres 9 y deshabilite el autovacuum
> poniendo el parametro en off
>
y porque hiciste eso?
> levanto el servicio de postgres y veo el top, a lo cual me permite percibir
> que
> hay varios procesos
Saludos lista
hace poco actualiza un servidor en postgres 9 y deshabilite el autovacuum
poniendo el parametro en off
autovacuum = off
levanto el servicio de postgres y veo el top, a lo cual me permite percibir
que
hay varios procesos de autovacuum con CPU asignado y en funcion
*PIDuser
siempre a la lista, y no hagas una pregunta nueva en una conversacion
que no tiene nada que ver
On 10/14/08, Humberto Guillermo Luna <[EMAIL PROTECTED]> wrote:
> Hola, mira soy nuevo en el tema postgres, trabajo en el poder judicial de
> sanjuan, y los muchachos de lexdoctor, han instalado aqui al
2008/10/13 Rodriguez Fernando <[EMAIL PROTECTED]>:
>
> Hola, mejor cambia a 8.3.3 u 8.3.4, porque creo que 8.3.2 tuvo un problema
> por lo cual estuvo poco tiempo disponible.
>
de hecho nunca se libero oficialmente
http://www.postgresql.org/docs/8.3/static/release-8-3-2.html
--
Atentamente,
Jai
resql.org
<mailto:[email protected]>
> Subject: Re: [pgsql-es-ayuda] autovacuum en 4.3.3
>
> Manuel Lamas escribió:
>
> > Hoy estoy poniendo la versión 4.3.3 y aparentemente
> > stats_start_collector y stats_row_level no existen
AIL PROTECTED]>
>
>
> > Date: Tue, 7 Oct 2008 20:30:21 -0400
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > CC: [email protected]
> > Subject: Re: [pgsql-es-ayuda] autovacuum en 4.3.3
> >
> > Manuel Lamas escribió:
> &g
> Date: Tue, 7 Oct 2008 20:30:21 -0400> From: [EMAIL PROTECTED]> To: [EMAIL
> PROTECTED]> CC: [email protected]> Subject: Re: [pgsql-es-ayuda]
> autovacuum en 4.3.3> > Manuel Lamas escribió:> > > Hoy estoy poniendo la
> versión 4.3.3 y a
Manuel Lamas escribió:
> Hoy estoy poniendo la versión 4.3.3 y aparentemente
> stats_start_collector y stats_row_level no existen mas. Aparte
> autovacuum esta por defecto : autovacuum = on.
Efectivamente, stats_start_collector y stats_row_level se fundieron en
una sola opcion que creo que es "tr
Wow, 4.3.3, esa una versión d la era d los dinosaurios. Creo q la ultima
versión es la 8.3.4.
ing. José Fermín Francisco Ferreras San Francisco de Macorís,
Rep. Dom.
> From: [EMAIL PROTECTED]
> To: [email protected]
> Subject: [pgsql-es-ayuda] autovacuum en 4.3.3
>
Hola lista.
En mis antiguos servidores tenia que configurar :
autovacuum = on
stats_start_collector = on
stats_row_level = on
para el autovacuum.
Hoy estoy poniendo la versión 4.3.3 y aparentemente stats_start_collector y
stats_row_level no existen mas. Aparte autovacuum esta por defecto
34 matches
Mail list logo
