Re: [PATCHES] pg_dump lock timeout - Mailing list pgsql-hackers

From daveg
Subject Re: [PATCHES] pg_dump lock timeout
Date
Msg-id 20080703125501.GS866@sonic.net
Whole thread Raw
In response to Re: [PATCHES] pg_dump lock timeout  ("Marko Kreen" <markokr@gmail.com>)
Responses Re: [PATCHES] pg_dump lock timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCHES] pg_dump lock timeout  (daveg <daveg@sonic.net>)
List pgsql-hackers
On Thu, Jul 03, 2008 at 11:15:10AM +0300, Marko Kreen wrote:
> On 5/11/08, daveg <daveg@sonic.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.

Agreed. I'll change it.

> - It would be more polite to do SET LOCAL instead SET.
>   (Eg. it makes safer to use pg_dump through pooler.)

Also agreed. Thanks.

> - 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.

I'd prefer to leave whatever policy is otherwise in place alone. I can see
use cases for either having or not having a timeout for pg_dump, but it does
seem  outside the scope of this patch.

Thanks for you review and comments.

-dg

--
David Gould       daveg@sonic.net      510 536 1443    510 282 0869
If simplicity worked, the world would be overrun with insects.

pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Resolving polymorphic functions with relateddatatypes
Next
From: Aaron Spiteri
Date:
Subject: Command execution