Re: Auto-vacuum is not running in 9.1.12 - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Auto-vacuum is not running in 9.1.12
Date
Msg-id 20150617211042.GB133018@postgresql.org
Whole thread Raw
In response to Re: Auto-vacuum is not running in 9.1.12  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Auto-vacuum is not running in 9.1.12  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Auto-vacuum is not running in 9.1.12  (Cédric Villemain <cedric@2ndQuadrant.com>)
Re: Auto-vacuum is not running in 9.1.12  (Robert Haas <robertmhaas@gmail.com>)
Re: Auto-vacuum is not running in 9.1.12  (Andres Freund <andres@anarazel.de>)
List 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

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: last_analyze/last_vacuum not being updated
Next
From: Tom Lane
Date:
Subject: Re: Auto-vacuum is not running in 9.1.12