-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
> Sorry if I missed it in the original thread, but what is the > use case you have in mind? A use case would be dumping a large table and wanting to load it into the database, but wanting to stop the job if it is still running an hour from now, when a maintenance window is scheduled to start. However, I think my objection is more philosophical, as we've changed from having pg_dump make a SQL representation of part or all of your database, into also having it force what it thinks should be the right environment as well. Yes, timeout can be a foot gun, but it's a foot gun that off by default, and must be explicitly turned on. The fact that a setting that kills long-running queries ends up killing long-running queries via psql -f seems worth a documentation warning, not a change in the textual representation of a database. I checked the archives and have yet to find a single instance in -bugs of anyone complaining about this. The closest I found was someone having problems with psql and -c, but they were specifically aware of the timeout and were trying (unseccessfully) to disable it first. For the record, I have no problem with disabling the timeout in both pg_dump and pg_restore. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200804171250 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkgHf/sACgkQvJuQZxSWSsiXOwCggD1P/SgPwOO3gJdlXKP5bU3l dWgAnRK5FNixLy8ajgkfI3Y/UpDyoeZB =qaA5 -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
