Re: Performance with the new security release?

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

In response to

Browse pgsql-hackers by date

  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