Bruce Momjian <[EMAIL PROTECTED]> writes:
> Greg Sabino Mullane wrote:
>>> Particularly consider using psql to restore a pg_dump
>>> dump --- are we going to add "SET statement_timeout=0"
>>> to the pg_dump file?
>>
>> I hope not. That should be the user's choice.
> Would anyone want to limit the load time for pg_dump? I can hardly see
> why.
I think we need to be careful to distinguish three situations:
* statement_timeout during pg_dump
* statement_timeout during pg_restore
* statement_timeout during psql reading a pg_dump script file
Only in the third case is it really trivial for the user to set an
appropriate timeout value before starting the script. (You can
manage it via PGOPTIONS in the other two cases, but it's not exactly
easy nor well-documented.)
To me, the killer reason for statement_timeout = 0 during pg_dump
is that without it, routine cron-driven dumps could fail, and the
user might not notice until he really really needed that dump.
Ooops.
In the second and third cases, you at least have an option to do it
over if a timeout zaps you. But it'd still likely be unpleasant,
especially if the restore already did a lot of work before getting
killed.
Offhand I don't see an argument in any of these scenarios why
a timeout kill is ever a good idea, but I'm willing to listen.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
