| From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
|---|---|
| To: | daveg <daveg(at)sonic(dot)net> |
| Cc: | pgsql-patches(at)postgresql(dot)org, hari(at)efrontier(dot)com, "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCHES] pg_dump lock timeout |
| Date: | 2008-07-03 08:15:10 |
| Message-ID: | e51f66da0807030115y2520ecbdie9d17f6312636f3@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
On 5/11/08, daveg <daveg(at)sonic(dot)net> wrote:
> Attached is a patch to add a commandline option to pg_dump to limit how long
> pg_dump will wait for locks during startup.
My quick review:
- It does not seem important enough to waste a short option on.
Having only long option should be enough.
- It would be more polite to do SET LOCAL instead SET.
(Eg. it makes safer to use pg_dump through pooler.)
- The statement_timeout is set back with "statement_timeout = default"
Maybe it would be better to do "= 0" here? Although such decision
would go outside the scope of the patch, I see no sense having
any other statement_timeout for actual dumping.
--
marko
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Cave-Ayland | 2008-07-03 09:01:23 | Re: WIP patch: reducing overhead for repeat de-TOASTing |
| Previous Message | Volkan YAZICI | 2008-07-03 08:10:36 | Concurrent Restores |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Markus Wanner | 2008-07-03 08:32:54 | Re: Regression test database name |
| Previous Message | Nikhils | 2008-07-03 06:52:48 | Re: Exposing keywords to clients |