diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 23ebc11..0b8d614 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1749,6 +1749,50 @@ include 'filename'
       </listitem>
      </varlistentry>
 
+     <varlistentry id="guc-synchronous-transfer" xreflabel="synchronous_transfer">
+      <term><varname>synchronous_transfer</varname> (<type>enum</type>)</term>
+      <indexterm>
+       <primary><varname>synchronous_transfer</> configuration parameter</primary>
+      </indexterm>
+      <listitem>
+       <para>
+        This parameter controls the synchronous nature of WAL transfer and
+        maintains file system level consistency between master server and
+        standby server. Specifies whether master server will wait for file
+        system level change (for example : modifying data page) before
+        corresponding WAL records are replicated to the standby server.
+       </para>
+       <para>
+        Valid values are <literal>commit</>, <literal>data_flush</> and
+        <literal>all</>. The default value is <literal>commit</>, meaning
+        that master only wait for transaction commits, this is equivalent
+        to turning off <literal>synchronous_transfer</> parameter and standby
+        server will behave as a <quote>synchronous standby </> in
+        Streaming Replication. When <literal>data_flush</>, master will
+        wait only for data page modifications but not for transaction
+        commits, hence the standby server will act as <quote>asynchronous
+        failback safe standby</>. When <literal> all</>, master will wait
+        for data page modifications as well as for transaction commits and
+        resultant standby server will act as <quote>synchronous failback safe
+        standby</>, to configure synchronous failback safe standby
+        <xref linkend="guc-synchronous-standby-names"> should be set.
+       </para>
+       <para>
+        Setting this parameter to <literal> commit</> will configure pure
+        Streaming Replication, on the other hand setting to <literal>
+        data_flush </> will make WAL transfer synchronous except transaction
+        commits. All WAL transfer can be made synchronous by setting this
+        parameter to <literal>all</> value.
+       </para>
+       <para>
+        Setting <literal>synchronous_transfer</> to <literal>data_flush</> or
+        <literal>all</> makes WAL transfer synchronous, but this wait is mostly
+        on background activities such as bgwriter. Hence this will not create
+        much performance overhead.
+       </para>
+      </listitem>
+     </varlistentry>
+
      <varlistentry id="guc-wal-sync-method" xreflabel="wal_sync_method">
       <term><varname>wal_sync_method</varname> (<type>enum</type>)</term>
       <indexterm>
@@ -2258,14 +2302,25 @@ include 'filename'
       </indexterm>
       <listitem>
        <para>
-        Specifies a comma-separated list of standby names that can support
-        <firstterm>synchronous replication</>, as described in
-        <xref linkend="synchronous-replication">.
-        At any one time there will be at most one active synchronous standby;
-        transactions waiting for commit will be allowed to proceed after
-        this standby server confirms receipt of their data.
-        The synchronous standby will be the first standby named in this list
-        that is both currently connected and streaming data in real-time
+        Specifies a comma-separated list of standby names. If this parameter
+        is set then standby will behave as synchronous standby in replication,
+        as described in <xref linkend="synchronous-replication"> or synchronous
+        failback safe standby, as described in <xref linkend="failback-safe">.
+        At any time there will be at most one active standby; when standby is
+        synchronous standby in replication, transactions waiting for commit
+        will be allowed to proceed after this standby server confirms receipt
+        of their data. But when standby is synchronous failback safe standby
+        data page modifications as well as transaction commits will be allowed
+        to proceed only after this standby server confirms receipt of their data.
+        If this parameter is set to empty value and
+        <xref linkend="guc-synchronous-transfer"> is set to <literal>data_flush</>
+        then standby is called as asynchronous failback safe standby and only
+        data page modifications will wait before corresponding WAL record is
+        replicated to standby.
+       </para>
+       <para>
+        Synchronous standby in replication will be the first standby named in
+        this list that is both currently connected and streaming data in real-time
         (as shown by a state of <literal>streaming</literal> in the
         <link linkend="monitoring-stats-views-table">
         <literal>pg_stat_replication</></link> view).
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index c8f6fa8..b2b42be 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1140,6 +1140,70 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
 
    </sect3>
   </sect2>
+
+  <sect2 id="failback-safe">
+     <title>Setting up failback safe standby</title>
+
+   <indexterm zone="high-availability">
+       <primary>Setting up failback safe standby</primary>
+   </indexterm>
+
+   <para>
+    PostgreSQL Streaming Replication offers durability, but if master
+    crashes and particular WAL record is unable to reach to standby
+    server, then that WAL record is present on master server but not
+    on standby server. In such a case master is ahead of standby server
+    in term of WAL records and Data in database. This will lead to
+    file-system level inconsistency between master and standby server.
+   </para>
+
+   <para>
+    Due to this inconsistency fresh backup of new master onto new standby
+    is needed to re-prepare HA cluster. Taking fresh backup can be very
+    time consuming process when database is of large size. In such a case
+    disaster recovery can take very long time if Streaming Replication is
+    used to setup the high availability cluster. The reason for this is,
+    Synchronous Replication makes WAL transfer synchronous at the time of
+    transaction commit. This will ensure the durability until the HA cluster
+    is up, but there are certain cases such as heap page update which will
+    cause inconsistency at the time of disaster if the standby is failed to
+    receive WAL record corresponding to this heap page update.
+   </para>
+
+   <para>
+    If HA cluster is configured with failback safe standby then master will
+    wait for data page modifications before corresponding WAL record is replicated
+    to standby. Failback safe standby has a control over all WAL transfer
+    and will not make any file system level change until gets a confirmation
+    from standby server. Hence avoids the need of fresh backup by maintaining
+    consistency.
+   </para>
+
+   <sect3 id="Failback-safe-config">
+    <title>Basic Configuration</title>
+   <para>
+    Failback safe standby can be asynchronous or synchronous in nature.
+    This will depend upon whether master will wait for transaction commit
+    or not. By default failback safe mechanism is turned off.
+   </para>
+
+   <para>
+    The first step to configure HA with failback safe standby is to setup
+    streaming replication. Configuring synchronous failback safe standby
+    requires setting up  <xref linkend="guc-synchronous-transfer"> to
+    <literal>all</> and <xref linkend="guc-synchronous-standby-names">
+    must be set to a non-empty value. This configuration will cause each
+    commit and data page modification to wait for confirmation that standby
+    has written corresponding WAL record to durable storage. Configuring
+    asynchronous failback safe standby requires only setting up
+     <xref linkend="guc-synchronous-transfer"> to <literal> data_flush</>.
+    This configuration will cause only data page modifications to wait
+    for confirmation that standby has written corresponding WAL record
+    to durable storage.
+   </para>
+
+  </sect3>
+  </sect2>
   </sect1>
 
   <sect1 id="warm-standby-failover">
@@ -1201,12 +1265,28 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
    </para>
 
    <para>
-    So, switching from primary to standby server can be fast but requires
-    some time to re-prepare the failover cluster. Regular switching from
-    primary to standby is useful, since it allows regular downtime on
-    each system for maintenance. This also serves as a test of the
-    failover mechanism to ensure that it will really work when you need it.
-    Written administration procedures are advised.
+    At the time of failover there is a possibility of file-system level
+    inconsistency between old primary and old standby server hence
+    fresh backup from new master onto old master is needed for Configuring
+    former primary server as a new standby server. Without taking fresh
+    backup even if the new standby starts, streaming replication does not
+    start successfully. The activity of taking backup can be fast for small
+    database but for large database requires more time to re-prepare the
+    failover cluster and could break the service line agreement of crash
+    recovery. This situation can arise when HA cluster is configured through
+    Streaming Replication. The need of fresh backup and problem of long
+    recovery time can be solved by using if HA cluster is configured with
+    failback safe standby see <xref linkend="failback-safe">.
+    Failback safe standby makes WAL transfer synchronous at required places
+    and maintains the file-system level consistency between master and standby
+    server and the former primary can be easily configured as new standby server.
+   </para>
+
+   <para>
+    Regular switching from primary to standby is useful, since it allows
+    regular downtime on each system for maintenance. This also serves as
+    a test of the failover mechanism to ensure that it will really work
+    when you need it. Written administration procedures are advised.
    </para>
 
    <para>
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 7868fe4..ec3bb53 100644
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -1557,6 +1557,14 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
        corruption) in case of a crash of the <emphasis>database</> alone.
       </para>
      </listitem>
+
+     <listitem>
+      <para>
+       Set <xref linkend="guc-synchronous-transfer"> to commit; there is no
+       need to guard against database inconsistency between master and standby.
+       and it is feasible to take fresh backup at failback time.
+      </para>
+     </listitem>
     </itemizedlist>
    </para>
   </sect1>
