Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id D4CB7B5F91D for ; Fri, 1 Jul 2011 00:37:10 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 04086-02-6 for ; Fri, 1 Jul 2011 03:37:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-qw0-f46.google.com (mail-qw0-f46.google.com [209.85.216.46]) by mail.postgresql.org (Postfix) with ESMTP id A5A19B5DFD4 for ; Fri, 1 Jul 2011 00:32:55 -0300 (ADT) Received: by qwk3 with SMTP id 3so1418174qwk.19 for ; Thu, 30 Jun 2011 20:32:55 -0700 (PDT) Received: by 10.229.18.129 with SMTP id w1mr2209454qca.108.1309491174902; Thu, 30 Jun 2011 20:32:54 -0700 (PDT) Received: from casanova1.SEINGALT ([190.131.87.127]) by mx.google.com with ESMTPS id r33sm2256257qcs.42.2011.06.30.20.32.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 20:32:54 -0700 (PDT) From: "Jaime Casanova" To: Fujii Masao Cc: Robert Haas , Simon Riggs , Tom Lane , Greg Stark , pgsql-hackers Subject: Re: time-delayed standbys Organization: 2ndQuadrant Ltd. References: <26007.1303309175@sss.pgh.pa.us> <27149.1303312506@sss.pgh.pa.us> Date: Thu, 30 Jun 2011 22:32:48 -0500 In-Reply-To: (Fujii Masao's message of "Fri, 1 Jul 2011 09:15:11 +0900") Message-ID: <87fwmqy8tb.fsf@casanova1.SEINGALT> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201107/1 X-Sequence-Number: 191100 Fujii Masao writes: > On Fri, Jul 1, 2011 at 2:25 AM, Robert Haas wrote: >>> Some actions aren't even transactional, such as DROP DATABASE, amongst >> >> Good point. =C2=A0We'd probably need to add a timestamp to the drop >> database record, as that's a case that people would likely want to >> defend against with this feature. > > This means that recovery_target_* code would also need to deal with > DROP DATABASE case. > there is no problem if you use "restore point" names... but of course you lose flexibility (ie: you can't restore to 5 minutes before now) mmm... a lazy idea: can't we just create a restore point wal record *before* we actually drop the database? then we won't need to modify logic about recovery_target_* (if it is only DROP DATABASE maybe that's enough about complicating code) and we can provide that protection since 9.1 --=20 Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL=20 Soporte 24x7, desarrollo, capacitaci=C3=B3n y servicios