pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Jaime Casanova <jaime@2ndquadrant.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <gsstark@mit.edu>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: time-delayed standbys
Date: Thu, 30 Jun 2011 22:32:48 -0500
Message-ID: <87fwmqy8tb.fsf@casanova1.SEINGALT> (raw)
In-Reply-To: <BANLkTi=+C3xP6M9TJZ6gBmQV8=97ZEQ_hg@mail.gmail.com>
References: <BANLkTi==TTzHDqWzwJDjmOf__8YuA7L1jw@mail.gmail.com>
	<BANLkTi=QScpDTkUw3iw6JaO15uUvx_P4qg@mail.gmail.com>
	<BANLkTimarB9eLhHpW73ja2oGvCaWNQuD6g@mail.gmail.com>
	<BANLkTi=hR3vGUDX-SQf=nFcL9ycmrQ6Fcg@mail.gmail.com>
	<BANLkTikPdjn98yjSR-VYywyjMe64wdrdDQ@mail.gmail.com>
	<26007.1303309175@sss.pgh.pa.us>
	<BANLkTikqGottQvyBzrXsARkaWMB2OEMGEA@mail.gmail.com>
	<27149.1303312506@sss.pgh.pa.us>
	<BANLkTin=22tyhK5zaNm7Nt-Q+MHcsNHdLg@mail.gmail.com>
	<BANLkTikFhVOhmf_XKERe=MkU3Ht_K7posQ@mail.gmail.com>
	<BANLkTi=COgk+8cieWxhM7YN9guYXOrDb_g@mail.gmail.com>
	<BANLkTingeD+XrxN-gDv0pzUMHrPcHWSF+A@mail.gmail.com>
	<BANLkTim8rKuUbDP=TxWmtfvZk8C1vmgmsw@mail.gmail.com>
	<BANLkTi=ufQk9i2Ria1U-c0VDUMUNxKjPgg@mail.gmail.com>
	<BANLkTi=33oiYV36cM_nOW7_Pi3t4E=P32g@mail.gmail.com>
	<BANLkTinSWseoHAYp7u+-3RHjQekd=5M2oA@mail.gmail.com>
	<BANLkTimGRb-cytLnibp1oxiUTkW=otrckg@mail.gmail.com>
	<BANLkTi=+C3xP6M9TJZ6gBmQV8=97ZEQ_hg@mail.gmail.com>

Fujii Masao <masao.fujii@gmail.com> writes:

> On Fri, Jul 1, 2011 at 2:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Some actions aren't even transactional, such as DROP DATABASE, amongst
>>
>> Good point.  We'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

-- 
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL 
Soporte 24x7, desarrollo, capacitación y servicios



view thread (114+ messages)  latest in thread

Message-ID: <87fwmqy8tb.fsf@casanova1.SEINGALT>
Permalink:  ../87fwmqy8tb.fsf@casanova1.SEINGALT/
Also on:    postgresql.org/message-id/87fwmqy8tb.fsf@casanova1.SEINGALT

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: jaime@2ndquadrant.com, masao.fujii@gmail.com, robertmhaas@gmail.com, simon@2ndquadrant.com, tgl@sss.pgh.pa.us, gsstark@mit.edu
  Subject: Re: time-delayed standbys
  In-Reply-To: <87fwmqy8tb.fsf@casanova1.SEINGALT>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox