Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 93577633EA4 for ; Fri, 12 Feb 2010 13:48:07 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 93960-06-2 for ; Fri, 12 Feb 2010 17:47:57 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mail.postgresql.org (Postfix) with ESMTP id 7B710633A4F for ; Fri, 12 Feb 2010 13:47:51 -0400 (AST) Received: by pzk39 with SMTP id 39so3159404pzk.15 for ; Fri, 12 Feb 2010 09:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=y5wYCfSMSi4+Llzm/a4Pc9CuNw4v91m6GvOCAW9nG1U=; b=C0MuJO1YAJ2lB7fJMA3WOYL4tXM74fX6/roKUTBRfNENHbu+nt9l81C7b8+sGGR4ZO gxQTkGWmT+9uR4ftcjkZC49Wsad2Xy9krRDdIEAZ7I0uTxCVHZjfbwj6Sg1cLa2a5GdZ 7EX/cTCiluvgaCq8l7kRShnNrFagqgqd73w9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=DrV0IjrWMkyTU6HZd/Rc9b/8+SprBBXj12mpw87SFbReQFJCQq/1l8cNcAIj8ULqXc FVYNCREw7Q05Uu3o8F1cs7o/LjC6B8G4bH7fzBVlqYO9QJTUh5KHF8U/mlL/8NMR62FE CXZsCjVTEahnrLXncJF8jP9kH30QiHkoSfOdU= MIME-Version: 1.0 Received: by 10.141.53.19 with SMTP id f19mr1133643rvk.233.1265996870087; Fri, 12 Feb 2010 09:47:50 -0800 (PST) In-Reply-To: References: <20100127152751.3B2047541B9@cvs.postgresql.org> <877hqjc2kk.fsf@hi-media-techno.com> <1265896250.7341.1627.camel@ebony> <4B740C6C.3010607@enterprisedb.com> <1265897834.7341.1714.camel@ebony> <4B7412BE.5030605@enterprisedb.com> <3f0b79eb1002112138n61a3258fg9986e50751d44ea0@mail.gmail.com> <1265979080.7341.3679.camel@ebony> <1265985269.7341.4105.camel@ebony> Date: Fri, 12 Feb 2010 17:47:49 +0000 X-Google-Sender-Auth: f9d4afffc69140b6 Message-ID: <407d949e1002120947x244a59a4o9df4a79ae636f999@mail.gmail.com> Subject: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL From: Greg Stark To: Dimitri Fontaine Cc: Simon Riggs , PostgreSQL-development , Heikki Linnakangas , Fujii Masao Content-Type: multipart/alternative; boundary=000e0cd291beba76ef047f6add6b X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5 tests=BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201002/1032 X-Sequence-Number: 157375 --000e0cd291beba76ef047f6add6b Content-Type: text/plain; charset=ISO-8859-1 so I from by like having the server doing the cleanup because it down by necessarily have the while picture. it down nt know of it is the only replica reading these log files our if the site policy is to keep them for disaster recovery purposes. I like having this as an return val command though. Or alternately now that we have read-only replicas you could implement this by polling the slaves and asking them what log position they are up to. greg On 12 Feb 2010 17:25, "Dimitri Fontaine" wrote: Simon Riggs writes: > Attached patch implements pg_standby for use as an > archive_cleanup_command, reusing existing cod... > Happy to add the archive_cleanup_command into main server as well, if > you like. Won't take long.... Would it be possible to have the server do the cleanup (and the cp for that matter) on its own or use a script? Either have archive_cleanup = on and either an commented out (empty) archive_cleanup_command and the same for the restore_command, or a special magic value, like 'postgresql' to activate the internal one. This way we have both a zero config working default setup and the flexibility to adapt to any archiving solution our user might already be using. A default archive_command would be nice too. Like you give it a directory name or a rsync path and it does the basic right thing. I'm not sure my detailed approach is the right one, but the birdview is to have the simple case really simple to setup, and the complex cases still possible. Default included archive, restore and cleanup commands would be awesome. Oh, and the basic simple case actually is with a remote standby. Without NFS or the like, no shared mount point for archiving. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subs... --000e0cd291beba76ef047f6add6b Content-Type: text/html; charset=ISO-8859-1

so I from by like having the server doing the cleanup because it down by necessarily have the while picture. it down nt know of it is the only replica reading these log files our if the site policy is to keep them for disaster recovery purposes.

I like having this as an return val command though. Or alternately now that we have read-only replicas you could implement this by polling the slaves and asking them what log position they are up to.

greg

On 12 Feb 2010 17:25, "Dimitri Fontaine" <dfontaine@hi-media.com> wrote:

Simon Riggs <simon@2ndQuadrant.com> writes:

> Attached patch implements pg_standby for use as an
> archive_cleanup_command, reusing existing cod...

> Happy to add the archive_cleanup_command into main server as well, if
> you like. Won't take long....

Would it be possible to have the server do the cleanup (and the cp for
that matter) on its own or use a script?

Either have archive_cleanup = on and either an commented out (empty)
archive_cleanup_command and the same for the restore_command, or a
special magic value, like 'postgresql' to activate the internal one.

This way we have both a zero config working default setup and the
flexibility to adapt to any archiving solution our user might already be
using.

A default archive_command would be nice too. Like you give it a
directory name or a rsync path and it does the basic right thing.

I'm not sure my detailed approach is the right one, but the birdview is
to have the simple case really simple to setup, and the complex cases
still possible. Default included archive, restore and cleanup commands
would be awesome.

Oh, and the basic simple case actually is with a remote standby. Without
NFS or the like, no shared mount point for archiving.

Regards,
--
dim


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs...

--000e0cd291beba76ef047f6add6b--