Joshua D. Drake wrote: > Tom Lane wrote: > >Robert Treat <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
