"Shahaf Abileah" <shahaf at redfin.com> writes:
> I just read this page: http://www.postgresql.org/docs/8.2/static/continuous-archiving.html:p>
>
> And it made me wonder whether this mechanism of continuous archiving
> and point-in-time recovery (PITR) can be used for replication.  In
> other words, Postgres already generates write-ahead-log files for
> all operations.  If you can transmit those files to another machine
> and replay them, continuously, then you have a form of
> replication.:p>

Yes, it is "a form of replication," in a somewhat analagous (but, for
many scenarios, superior) way to the way that using pg_dump to dump
and psql to restore a database may be considered "a form of
replication."

> But, it's not clear if this is possible.  The article linked above
> talks about doing continuous archiving, but it doesn't talk about
> doing continuous recovery.  Instead, it talks about doing a single
> point-in-time recovery.  Moreover, this recovery requires the target
> (``slave'') machine to be offline during the recovery process.:p>

PITR is certainly "possible" to use.

Whether its behaviour is suitable for your requirements is another
matter.  As noted, the "slave" is held offline throughout the recovery
process, which means it can't be used to satisfy queries, as is the
case with Slony-I subscribers.

> Does anyone know whether it's possible to use Postgres' archiving
> and PITR for replication?:p>

As noted above, yes, it certainly can, as long as it is acceptable to
not be able to use slaves that are in recovery mode.

We've had at least one case where we have considered using PITR as a
replication solution since its tradeoffs all seemed satisfactory.
(The system for which it was considered hasn't gone into production,
which is why I say "considered," rather than "deployed.")

> By the way, if it can, it seems that::p>

> 1.      It would have the advantage that various operations are
> handled in a more natural manner than with Slony (e.g. DDL):p>
>
> 2.      It would have the disadvantage that you can't be choosy
> about what to replicate -- you get the entire DB cluster, or nothing
> at all.:p>
>
> Is that correct?:p>

Yes, those would seem to be merits and demerits of using PITR as a
replication system.
-- 
output = reverse("ofni.sesabatadxunil" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/advocacy.html
The quickest way to a man's heart is through his chest, with an axe.