Re: Understanding PG9.0 streaming replication feature

Dan Birken wrote:
> (I am not the OP, but recently went through the same thing so I'll chime in)
>
> Reading through the documentation now (albeit with a now pretty good
> understanding of how everything works), I think the main confusing thing is
> how different bits which apply to file-base log shipping, streaming
> replication and both of them are thrown together on this
> page<http://developer.postgresql.org/pgdocs/postgres/warm-standby.html>,
> making it difficult to figure out what you need to know if you are just
> looking to implement streaming replication.

Nice idea to use color to highlight stuff.  You are right that the
streaming docs were added later, and seem out of place.

I have applied the attached patch so the text is more fluid.  Let me
know if you have additional suggestions.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 717347c..ce3f264 100644
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
*************** protocol to make nodes agree on a serial
*** 486,503 ****
    <para>
     Directly moving WAL records from one database server to another
     is typically described as log shipping. <productname>PostgreSQL</>
!    implements file-based log shipping, which means that WAL records are
!    transferred one file (WAL segment) at a time. WAL files (16MB) can be
     shipped easily and cheaply over any distance, whether it be to an
     adjacent system, another system at the same site, or another system on
     the far side of the globe. The bandwidth required for this technique
     varies according to the transaction rate of the primary server.
!    Record-based log shipping is also possible with streaming replication
!    (see <xref linkend="streaming-replication">).
    </para>

    <para>
!    It should be noted that the log shipping is asynchronous, i.e., the WAL
     records are shipped after transaction commit. As a result, there is a
     window for data loss should the primary server suffer a catastrophic
     failure; transactions not yet shipped will be lost.  The size of the
--- 486,504 ----
    <para>
     Directly moving WAL records from one database server to another
     is typically described as log shipping. <productname>PostgreSQL</>
!    implements file-based log shipping by transfering WAL records
!    one file (WAL segment) at a time. WAL files (16MB) can be
     shipped easily and cheaply over any distance, whether it be to an
     adjacent system, another system at the same site, or another system on
     the far side of the globe. The bandwidth required for this technique
     varies according to the transaction rate of the primary server.
!    Record-based log shipping is more granular and streams WAL changes
!    incrementally over a network connection (see <xref
!    linkend="streaming-replication">).
    </para>

    <para>
!    It should be noted that log shipping is asynchronous, i.e., the WAL
     records are shipped after transaction commit. As a result, there is a
     window for data loss should the primary server suffer a catastrophic
     failure; transactions not yet shipped will be lost.  The size of the
*************** protocol to make nodes agree on a serial
*** 505,512 ****
     <varname>archive_timeout</varname> parameter, which can be set as low
     as a few seconds.  However such a low setting will
     substantially increase the bandwidth required for file shipping.
!    If you need a window of less than a minute or so, consider using
!    streaming replication (see <xref linkend="streaming-replication">).
    </para>

    <para>
--- 506,513 ----
     <varname>archive_timeout</varname> parameter, which can be set as low
     as a few seconds.  However such a low setting will
     substantially increase the bandwidth required for file shipping.
!    Streaming replication (see <xref linkend="streaming-replication">)
!    allows a much smaller window of data loss.
    </para>

    <para>