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
19 matches
Mail list logo
