Re: Diagnosing a massive toast file

Поиск
Список
Период
Сортировка
От Avinash Kumar
Тема Re: Diagnosing a massive toast file
Дата
Msg-id CAN0TujcdPFwWUAJvkpNfRHD6thg-28HuxyZN4XghnH8ojhhg_Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Diagnosing a massive toast file  (Wells Oliver <wells.oliver@gmail.com>)
Список pgsql-admin


On Mon, Aug 5, 2019 at 2:43 PM Wells Oliver <wells.oliver@gmail.com> wrote:
Thanks, that was it exactly. PGAdmin session opened for a week. Argh. Gotta have some conversations with some folks.

Do you guys have any kind of regular monitoring in place to flag users who don't politely close their connections?
pg_stat_activity view would do the trick for you. 
Search for the connections that are running long for more than a few hours ? or days ?
See if any idle in transactions that have now() - state_change, more than a few mins ? or hours ? or days ?
 

On Mon, Aug 5, 2019 at 10:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Wells Oliver <wells.oliver@gmail.com> writes:
> As a follow up, n_dead_tup from pg_stat_sys_tables for this TOAST table is
> 7447444, live tuples, 623982, and tup_del 20823469. vacuum_count is 0.

> Why can't I free those rows up?

Old open transaction somewhere (possibly a prepared transaction?).
Or a replication slot that's holding back the xmin horizon due to
not keeping up.

                        regards, tom lane


--


--
9000799060

В списке pgsql-admin по дате отправления:

Предыдущее
От: Wells Oliver
Дата:
Сообщение: Re: Diagnosing a massive toast file
Следующее
От: Igor Neyman
Дата:
Сообщение: RE: Diagnosing a massive toast file