| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | Greg Sabino Mullane <greg(at)turnstep(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |
| Date: | 2008-04-17 19:48:27 |
| Message-ID: | 4807A98B.2000600@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Greg Sabino Mullane wrote:
> 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.
statement_timeout is pretty useless for that purpose, because it limits
the time on a per-statement basis. It would cancel the COPY of any
tables larger than X, but if you have multiple tables (a partitioned
table, perhaps) just below the threshold, they would all be dumped even
though the cumulative time is well beyond statement_timeout.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Denne | 2008-04-17 20:32:01 | Re: count(*) performance improvement ideas |
| Previous Message | Heikki Linnakangas | 2008-04-17 19:28:04 | Re: DROP DATABASE vs patch to not remove files right away |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-04-17 20:53:08 | Re: Proposed patch - psql wraps at window width |
| Previous Message | Greg Sabino Mullane | 2008-04-17 16:51:52 | Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout |