DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:references;
	b=XgLGf84L6fSc2zsTg5tx8WKd3Nacoo1b98hmWXdlwbULY0wubYS2sdPF0g9kAACt/y
	cHHeDAYzCT7UEhjCWHB1xZVTTCzw+fMYeJA6t2mOii/arocYVr29ecpjGKDY8oo7NeBk
	OtgQ/PqEwryW+VywO8x2DzpNk+fMK0K+Wmd/w=
Message-ID: <e51f66da0807030115y2520ecbdie9d17f6312636f3@mail.gmail.com>
Date: Thu, 3 Jul 2008 11:15:10 +0300
From: "Marko Kreen" <markokr@gmail.com>
To: daveg <daveg@sonic.net>
Subject: Re: [PATCHES] pg_dump lock timeout
Cc: pgsql-patches@postgresql.org, hari@efrontier.com,
	"Postgres Hackers" <pgsql-hackers@postgresql.org>
In-Reply-To: <20080511113047.GV5673@sonic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20080511113047.GV5673@sonic.net>

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