| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Prakash Itnal <prakash074(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, rasna(dot)t(at)nokia(dot)com, sandhya(dot)k_s(at)nokia(dot)com |
| Subject: | Re: Auto-vacuum is not running in 9.1.12 |
| Date: | 2015-06-17 21:10:42 |
| Message-ID: | 20150617211042.GB133018@postgresql.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> In HEAD this doesn't seem like it could cause an indefinite sleep because
> if nothing else, sinval queue overrun would eventually wake the launcher
> even without any manual action from the DBA. But the loop logic is
> different in 9.1.
Just waiting for the sinval queue to overrun doesn't sound like a great
mechanism to me.
> launcher_determine_sleep() does have a minimum sleep time, and it seems
> like we could fairly cheaply guard against this kind of scenario by also
> enforcing a maximum sleep time (of say 5 or 10 minutes). Not quite
> convinced whether it's worth the trouble though.
Yeah, the case is pretty weird and I'm not really sure that the server
ought to be expected to behave. But if this is actually the only part
of the server that misbehaves because of sudden gigantic time jumps, I
think it's fair to patch it. Here's a proposed patch.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Clamp-autovacuum-launcher-sleep-time-to-5-minutes.patch | text/x-diff | 976 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-06-17 21:22:43 | Re: Auto-vacuum is not running in 9.1.12 |
| Previous Message | Peter Eisentraut | 2015-06-17 20:17:02 | Re: last_analyze/last_vacuum not being updated |