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 ?
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
--Wells Oliver
wells.oliver@gmail.com
9000799060
В списке pgsql-admin по дате отправления: