Re: [GENERAL] statement_timeout - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [GENERAL] statement_timeout
Date
Msg-id 1164132125.3841.387.camel@silverbirch.site
Whole thread Raw
In response to Re: [GENERAL] statement_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] statement_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2006-11-21 at 12:14 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > On Thu, 2006-11-16 at 13:50 -0500, Tom Lane wrote:
> >> =?iso-8859-2?Q?Marcin_Ma=F1k?= <marcin.mank@gmail.com> writes:
> >>> I have an unconfirmed feeling that autovac does not like system-wide
> >>> statement_timeout.
> >>
> >> If you have it set to less than the time needed to do a vacuum, then
> >> yes, autovac will fail.  You expected differently?  Do you think it's
> >> a good idea for autovac to ignore statement_timeout?  (Maybe it is,
> >> but I suspect we'd get complaints about that too.)
>
> > Autovac *must* ignore statement_timeout if it is doing a wraparound
> > avoidance scan, surely?
>
> Hmm.  Good point.  Shall we just make it ignore statement_timeout all
> the time, then?  We already have it overriding zero_damaged_pages ...

Hmmm.... ponders a difficult choice:

Having an autovacuum cancelled doesn't seem to have huge utility, but
then neither does allowing a stupidly long autovacuum either.

On balance if it is running, it is running for a reason, so to interrupt
that reason is not useful behaviour. If anybody wants their autovacuums
to run in less time they can give it more memory.

So yes, autovacuum should ignore statement_timeout all of the time.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From:
Date:
Subject: Re: Tsearch + polish ispell + polish locale
Next
From: Teodor Sigaev
Date:
Subject: Re: Tsearch + polish ispell + polish locale