From: | Artem Tomyuk <admin(at)leboutique(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hubert Lubaczewski <depesz(at)depesz(dot)com>, Keith <keith(at)keithf4(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: how to shrink pg_attribute table in some database |
Date: | 2018-03-26 15:51:10 |
Message-ID: | CANYYVq+N8Ay4f-2_TPPkmkJ8u-t-RW7XUF_X+7HYumDDSEXh+g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
our monitoring shows that this bloat happened within 72h.
after query was fixed - db stopped to grow in size.... so what other ideas?
2018-03-26 18:46 GMT+03:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Artem Tomyuk <admin(at)leboutique(dot)com> writes:
> > There was broken query that every time was creating temp table and than
> was
> > trying to insert into this table some data in another query but within
> > single connection, what happened next that second query was unable to be
> > executed because of syntax error (yes, human factor), this query was
> > repeated every minute by cron 24/7.
>
> One temp table per minute doesn't explain this amount of bloat, unless
> autovacuum had failed to process pg_attribute for a really really long
> time. It would be good to figure out why that happened.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Ahmed, Nawaz | 2018-03-27 02:54:55 | RE: Backup Tool |
Previous Message | Tom Lane | 2018-03-26 15:46:21 | Re: how to shrink pg_attribute table in some database |