Re: Proposal: Log inability to lock pages during vacuum - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Proposal: Log inability to lock pages during vacuum
Date
Msg-id 20141021004955.GM7176@awork2.anarazel.de
Whole thread Raw
In response to Re: Proposal: Log inability to lock pages during vacuum  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On 2014-10-20 19:43:38 -0500, Jim Nasby wrote:
> On 10/20/14, 7:31 PM, Andres Freund wrote:
> >On 2014-10-20 19:18:31 -0500, Jim Nasby wrote:
> >>>In the meantime, I think it's worth adding this logging. If in fact this basically never happens (the current
assumption),it doesn't hurt anything. If it turns out our assumption is wrong, then we'll actually be able to fin> that
out.:)
> >It does happen, and not infrequently. Just not enough pages to normally
> >cause significant bloat. The most likely place where it happens is very
> >small tables that all connections hit with a high frequency. Starting to
> >issue high volume log spew for a nonexistant problem isn't helping.
> 
> How'd you determine that? Is there some way to measure this?

You'd seen individual pages with too old dead rows in them.

> >If you're super convinced this is urgent then add it as a*single*
> >datapoint inside the existing messages. But I think there's loads of
> >stuff in vacuum logging that are more important this.
> 
> See my original proposal; at it's most intrusive this would issue one
> warning per (auto)vacuum if it was over a certain threshold.

Which would vastly increase the log output for setups with small tables
and a nonzero log_autovacuum_min_duration.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Autovacuum fails to keep visibility map up-to-date in mostly-insert-only-tables
Next
From: Wim Lewis
Date:
Subject: Re: Patch: Add launchd Support