"J. Andrew Rogers" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
