On Mon, 2011-01-17 at 14:46 -0500, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> > However, we'd want a separate lock timeout for autovac, of course. I'm
> > not at all keen on a *statement* timeout on autovacuum; as long as
> > autovacuum is doing work, I don't want to cancel it. Also, WTF would we
> > set it to?
>
> Yeah --- in the presence of vacuum cost delay, in particular, a
> statement timeout seems about useless for AV.
>
> > Going the statement timeout route seems like a way to create a LOT of
> > extra work, troubleshooting, getting it wrong, and releasing patch
> > updates. Please let's just create a lock timeout.
>
> Do we actually need a lock timeout either? The patch that was being
> discussed just involved failing if you couldn't get it immediately.
> I suspect that's sufficient for AV. At least, nobody's made a
> compelling argument why we need to expend a very substantially larger
> amount of work to do something different.
I have a patch to do this BUT the log message is harder. Until we grab
the lock we can't confirm the table still exists, so we can't get the
name for it. The whole point of this is logging the names of tables for
which we have failed to AV. Suggestions?
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
