Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 5BFF2632DE5 for ; Thu, 11 Feb 2010 10:01:31 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 36527-01-2 for ; Thu, 11 Feb 2010 14:01:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from oak.highrise.ca (oak.highrise.ca [70.38.99.169]) by mail.postgresql.org (Postfix) with ESMTP id 9EA76632A9A for ; Thu, 11 Feb 2010 10:01:20 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by oak.highrise.ca (Postfix) with ESMTP id 60CE0AC2BC; Thu, 11 Feb 2010 09:01:18 -0500 (EST) Date: Thu, 11 Feb 2010 09:01:18 -0500 From: Aidan Van Dyk To: Heikki Linnakangas Cc: Simon Riggs , Fujii Masao , PostgreSQL-development Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL Message-ID: <20100211140118.GB14128@oak.highrise.ca> References: <20100127152751.3B2047541B9@cvs.postgresql.org> <3f0b79eb1002092105r21e009d3v468496058ba04392@mail.gmail.com> <4B726120.80007@enterprisedb.com> <1265884657.7341.1192.camel@ebony> <4B73F678.8070109@enterprisedb.com> <1265891248.7341.1346.camel@ebony> <4B73FB99.4080403@enterprisedb.com> <1265893599.7341.1454.camel@ebony> <4B740613.5090004@enterprisedb.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qrgsu6vtpU/OV/zm" Content-Disposition: inline In-Reply-To: <4B740613.5090004@enterprisedb.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.512 tagged_above=-10 required=5 tests=AWL=0.087, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/858 X-Sequence-Number: 157201 --Qrgsu6vtpU/OV/zm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Heikki Linnakangas [100211 08:29]: > To suppport a restore_command that does the sleeping itself, like > pg_standby, would require a major rearchitecting of the retry logic. And > I don't see why that'd desirable anyway. It's easier for the admin to > set up using simple commands like 'cp' or 'scp', than require him/her to > write scripts that handle the sleeping and retry logic. But colour me confused, I'm still not understanding why this is any different that with normal PITR recovery. So even with a plain "cp" in your recovery command instead of a sleep+copy (a la pg_standby, or PITR tools, or all the home-grown solutions out thery), I'm not seeing how it's going to get "half files". The only way I can see that is if you're out of disk space in your recovering pg_xlog. It's well know in PostgreSQL wal archivne - you don't just "shove" files into the archive, you make sure they appear there with the right name atomically. And if the master is only running the archive command on whole WAL files, I just don't understand this whole short wal problem. And don't try and tell me your just "poaching" files from a running cluster's pg_xlog directory, because I'm going to cry... a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. --Qrgsu6vtpU/OV/zm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFLdA2uuVxNPsxNPScRAhZ4AJ42DVwUbMy5g7KsoKLcAH7RgH/5xACfS4MA idhvjRY7B6tW+wFTmxFk03w= =mAb2 -----END PGP SIGNATURE----- --Qrgsu6vtpU/OV/zm--