Re: PITR for replication?

"J. Andrew Rogers" <jrogers(at)neopolitan(dot)com> writes:

> 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.

Well "replication" is one of those things that means different things to
different people. IMHO, this is one of the simpler, more reliable, mechanisms
and would be nice to have. And you're right that it shouldn't require much
more work, in fact it's probably easier than a lot of other cases that PITR
requires.

For a long time Oracle has supported this mechanism for running warm standby
databases. Basically you maintain a second database and every time an archived
log is finished you ship it over and immediately "restore" it on the standby
machine. Whenever you have a failure you can quickly fail over to the standby
database which is all ready to go and up-to-date within minutes of your
failure.

Since 8i Oracle has also supported a more advanced version where you can open
the standby database in read-only mode. This makes it useful for running batch
reports and so on. In postgres this wouldn't work nearly so well since even
read-only queries require write access to the database in postgres. Perhaps
it's not nearly so urgent since running long-running batch queries on a busy
system in postgres doesn't pose all the same dangers it does in Oracle (the
dreaded "snapshot too old" error) -- though there are other analogous dangers
(fsm settings being too small unexpectedly).

--
greg