Re: PITR for replication? - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: PITR for replication?
Date
Msg-id m33c7nxepi.fsf@wolfe.cbbrowne.com
Whole thread Raw
In response to Update on PITR  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
Oops! jrogers@neopolitan.com ("J. Andrew Rogers") was seen spray-painting on a wall:
> I may be completely missing the point here, but it looks to me as
> though the PITR archival mechanism is also most of a native
> replication facility.  Is there anyone reason this couldn't be
> extended to replication, and if so, is anyone planning on using it
> as such?
>
> My memory is fuzzy on this point, but I seem to recall that this is
> (was?) how replication is more-or-less done for many of the big
> commercial RDBMS.

What isn't clear to me at this point is whether PITR is set up to
allow the database to remain "live and accessible" while updates are
being loaded in.

If that's NOT the case, then it is in no way a meaningful replacement
for replication, vastly useful though it may be.

At those times I have seen Oracle(tm) archive logs being applied to
support PITR-related functionality, the DB hasn't been "up and
running."  I suspect that may have changed by now, which would
certainly be handy for replication.
-- 
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://cbbrowne.com/info/multiplexor.html
As of next Tuesday, all terminal input will be line-at-a-time.
Please update your programs.


pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: Function to kill backend
Next
From: Chris Browne
Date:
Subject: Re: Update on PITR