Thread: Re: [PATCHES] pg_dump lock timeout

Re: [PATCHES] pg_dump lock timeout

From
"Marko Kreen"
Date:
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

Re: [PATCHES] pg_dump lock timeout

From
daveg
Date:
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.

Re: [PATCHES] pg_dump lock timeout

From
Tom Lane
Date:
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

Re: [PATCHES] pg_dump lock timeout

From
daveg
Date:
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.