Re: Autovacuum vs statement_timeout

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Bruce asks:
>>> 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.

Not for pg_dump, but for psql, as you stated above. I don't
have a problem adding it to pg_dump or pg_restore. They are
single, atomic actions out of the control of the user. Restoring
a pg_dump'ed file through psql, on the other hand, should not
assume that the user might not want to keep or set their own
timeout, perhaps because they want to limit the load on the
server, or because of vacuuming concerns. Recall that pg_dump
is not just used to restore entire systems: we can dump schemas,
tables, and in the near future may even have the ability to
dump different classes (schema, data, constraints).

Hard-coding a forced option to the top of a potentially ginormous
and hard-to-edit file that really has nothing to do with the data
itself seems the wrong way to do things. It's not as if we've been
inundated on the lists with tales of people getting caught on
custom statement_timeouts when importing dumps.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200803111959
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkfXHqMACgkQvJuQZxSWSsgifQCgthvDCTiKhw/3A4S1na1mvlOB
+MQAn2baL34c8k3FV+f2CUAn7GwDewrN
=x24Q
-----END PGP SIGNATURE-----