Before going through something like delayed replication, you really want to consider using zfs or lvm and taking regular snapshots on your hot or warm standby. In the event of the accidental table drop, you can just roll back to the snapshot prior and then do PITR from there.
Greg Haase On Fri, Oct 25, 2013 at 11:14 PM, Jayadevan <maymala.jayade...@gmail.com>wrote: > Alan Hodgson wrote > > Well, yeah. The point was that you possibly could run it for a while to > > "catch > > up" without taking a new base backup if you desired. You should also keep > > copies of it for PITR. > > Something like this - > delayed replication > <http://dev.mysql.com/doc/refman/5.6/en/replication-delayed.html> might > help. I could say lag by 12 hours, or 10000 transactions... > > > > -- > View this message in context: > http://postgresql.1045698.n5.nabble.com/PostgreSQL-Point-In-Time-Recovery-tp5775717p5775997.html > Sent from the PostgreSQL - general mailing list archive at Nabble.com. > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >