Re: Autovacuum vs statement_timeout

Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > Alvaro Herrera wrote:
> >> Hmm, AFAIR subsequent investigation led to the discovery that autovacuum
> >> is not affected by statement_timeout.
>
> > Right -- see
> > http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/80044/focus=93847
>
> Or even more to the point, look into autovacuum.c:
>
>     /*
>      * Force statement_timeout to zero to avoid a timeout setting from
>      * preventing regular maintenance from being executed.
>      */
>     SetConfigOption("statement_timeout", "0", PGC_SUSET, PGC_S_OVERRIDE);
>
> > So your documentation changes are incorrect.
>
> Indeed.  But wasn't the start of this thread a mention that pg_dump
> ought to have a similar defense?  AFAIR it does not, so there's still
> a small TODO.

OK, I have added a documentation mention but removed the mention of
autovacuum.  I have also added this TODO:

        o Prevent pg_dump/pg_restore from being affected by
          statement_timeout

          Using psql to restore a pg_dump dump is also affected.

Particularly consider using psql to restore a pg_dump dump --- are we
going to add "SET statement_timeout=0" to the pg_dump file?

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/config.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v
retrieving revision 1.170
diff -c -c -r1.170 config.sgml
*** doc/src/sgml/config.sgml    10 Mar 2008 12:55:13 -0000    1.170
--- doc/src/sgml/config.sgml    11 Mar 2008 15:38:41 -0000
***************
*** 3877,3882 ****
--- 3877,3888 ----
          logged.  A value of zero (the default) turns off the
          limitation.
         </para>
+
+        <para>
+         Setting <varname>statement_timeout</> in
+         <filename>postgresql.conf</> is not recommended because it
+         affects all sessions.
+        </para>
        </listitem>
       </varlistentry>