Joshua D. Drake wrote:
> Tom Lane wrote:
> >Robert Treat <xzilla@users.sourceforge.net> writes:
> >>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.
> >
> >The worst-case scenario here is that your server fails and you discover
> >that all your backups are corrupt because you didn't notice pg_dump was
> >failing due to statement_timeout. (Maybe it just recently started to
> >fail because your biggest table grew past the point at which the COPY
> >command exceeded statement_timeout.)
> >
> >I'm not excited about the other ones but I can see the argument for
> >making pg_dump force the timeout to 0.
>
> I guess my point is, if you are knowledgeable enough to actually set a
> statement_timeout, you are likely knowledgeable enough to know how to
> turn it off for programs like pg_dump.
I think that is too strong an assumption, which is why I'm planning to
back-patch the change to reset statement_timeout to 0 on autovacuum till
8.0, as discussed. I think I should also backpatch the change to set
zero_damaged_pages as well (which is not on 8.0 AFAIR).
It's very very easy to change things in postgresql.conf. Actually
knowing what you are doing (i.e. thinking on the consequences on VACUUM
and such) is a whole another matter.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support