Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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.
> This concrete case if of course valid, but if you take a step back,
> there are about half a dozen ways to configure the server to make
> pg_dump fail.
Sure, but I think in a lot of situations there is a use-case for
a nonzero default statement_timeout, so it seems to me worthwhile
to protect pg_dump from that rather than let DBAs find out the
hard way. Also, statement_timeout is particularly nasty in that
you may not see any failure when you first set up and test your
dump strategy. It'll get you after your tables have grown, or
on a day when there's particularly heavy activity concurrent
with the dump.
> # DON'T SET THIS PARAMETER IN THE CONFIGURATION FILE OR YOUR BACKUPS WILL FAIL
If there are any parameters for which that is actually appropriate,
wouldn't it be *more* appropriate to flat-out prevent them from
being set from the config file? I believe we have a GUC variable
flag already for things that shouldn't be in the file, but it's
not enforced.
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
