Thread: Re: [PATCHES] pg_dump lock timeout
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. - 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
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.
daveg <daveg@sonic.net> writes:
> On Thu, Jul 03, 2008 at 11:15:10AM +0300, Marko Kreen wrote:
>> - 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.
The policy in place in CVS HEAD is that pg_dump explicitly sets
statement_timeout to 0. Setting it to default would break that,
and will certainly not be accepted.
regards, tom lane
On Thu, Jul 03, 2008 at 05:55:01AM -0700, daveg wrote: > 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. On second glance, pg_dump sets lots of variables without using SET LOCAL. I think fixing that must be the subject of a separate patch as fixing just one of many will only cause confusion. > > - 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. As it happens, another patch has set the policy to "statement_timeout = 0", so I will follow that. I'm sending in the revised patch today. -dg -- David Gould daveg@sonic.net 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects.