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. A
misconfigured pg_hba.conf would also do it. And if the server isn't running,
should we start it? If we take a base backup, and archiving isn't enabled,
should we enable it?
Perhaps we shouldn't paper over configuration problems in inconsistent and ad
hoc ways, and instead give useful configuration advice and encourage users to
monitor their background jobs, which they will have to do anyway, even if we
solve a misconfigured statement_timeout for them.
# DON'T SET THIS PARAMETER IN THE CONFIGURATION FILE OR YOUR BACKUPS WILL FAIL
could be a start.
