From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Anne Rosset <arosset(at)collab(dot)net> |
Cc: | Steve Singer <steve(at)ssinger(dot)info>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance with the new security release? |
Date: | 2013-04-23 15:08:34 |
Message-ID: | 20130423150834.GM2169@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Anne Rosset wrote:
> Thanks Steve.
> I found this: http://www.postgresql.org/docs/current/static/release-9-2-3.html
> "
> Fix performance problems with autovacuum truncation in busy workloads (Jan Wieck)
> Truncation of empty pages at the end of a table requires exclusive lock, but autovacuum was coded to fail (and release the table lock) when there are conflicting lock requests. Under load, it is easily possible that truncation would never occur, resulting in table bloat. Fix by performing a partial truncation, releasing the lock, then attempting to re-acquire the lock and continue. This fix also greatly reduces the average time before autovacuum releases the lock after a conflicting request arrives."
>
> So that is not the fix?
>
> (Sorry to ask a second time but I really need to make sure).
That's the commit that created the bug, AFAIU. It's a fix for a serious
problem, but we overlooked that it introduced some other problems which
is what you're now seeing.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2013-04-23 15:28:33 | Re: Enabling Checksums |
Previous Message | Alvaro Herrera | 2013-04-23 14:59:43 | Re: putting a bgworker to rest |