On Tuesday 17 April 2007 18:38, Jim C. Nasby wrote:
> On Tue, Apr 17, 2007 at 12:51:51PM -0700, Joshua D. Drake wrote:
> > Jim C. Nasby wrote:
> > >On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
> > >>Tom Lane wrote:
> > >>>I seem to remember that we'd agreed that autovacuum should ignore any
> > >>>globally set statement_timeout, on the grounds that a poorly chosen
> > >>>setting could indefinitely prevent large tables from being vacuumed.
> > >>
> > >>On a vaguely related matter, should programs such as pg_dump, vacuumdb,
> > >>and reindexdb disable statement_timeout?
> > >
> > >Youch... yes, they should IMO. Add clusterdb, pg_dumpall and pg_restore
> > >to that list as well (really, pg_dump(all) should output a command to
> > >disable statement_timeout).
> >
> > I don't know if that should be a default or not. It is certainly easy
> > enough to disable it should you want to.
>
> How would you disable it for those command-line utilities? Or are you
> referring to disabling it via an ALTER ROLE SET ... for superusers?
>
> ISTM current behavior is a bit of a foot-gun. These are administrative
> shell commands that aren't going to be run by Joe-user.
I'm with Joshua on this one. Statement_timeout is often used as a means for
protection from long running statements due to server load and locking and
all of the above commands can certainly fall into that area. If people feel
strongly that the command line programs need a way to circumvent it, add
a --ignore-statement-timeout option or similar mechanism.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
