From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: We need to log aborted autovacuums |
Date: | 2011-01-17 01:36:32 |
Message-ID: | 1295228192.3282.1891.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2011-01-16 at 12:50 -0800, Josh Berkus wrote:
> On 1/16/11 11:19 AM, Simon Riggs wrote:
> > I would prefer it if we had a settable lock timeout, as suggested many
> > moons ago. When that was discussed before it was said there was no
> > difference between a statement timeout and a lock timeout, but I think
> > there clearly is, this case being just one example.
>
> Whatever happend to lock timeouts, anyway? We even had some patches
> floating around for 9.0 and they disappeared.
>
> 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?
> 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.
I agree with you, but if we want it *this* release, on top of all the
other features we have queued, then I suggest we compromise. If you hold
out for more feature, you may get less.
Statement timeout = 2 * (100ms + autovacuum_vacuum_cost_delay) *
tablesize/(autovacuum_vacuum_cost_limit / vacuum_cost_page_dirty)
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-01-17 01:41:53 | Re: limiting hint bit I/O |
Previous Message | Fujii Masao | 2011-01-17 01:15:46 | Re: auto-sizing wal_buffers |