Replace "slave" to "standby" in documentation for consistent terminology.

Almost all of the terms in docs and messages were replaced, but still
remains in a few comments and README files in codes.

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 624adb9d6d1b667e24b389697c415e05bd406e86..2f271efc4c90a884f211e2792855b49888b7a3bd 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Backup and Restore
@@ -1425,11 +1425,11 @@ pg_dumpall -p 5432 | psql -d postgres -p 6543
 
   
    It is also possible to use replication methods, such as
-   Slony, to create a slave server with the updated version of
-   PostgreSQL.  The slave can be on the same computer or
+   Slony, to create a standby server with the updated version of
+   PostgreSQL.  The standby can be on the same computer or
    a different computer.  Once it has synced up with the master server
    (running the older version of PostgreSQL), you can
-   switch masters and make the slave the master and shut down the older
+   switch masters and make the standby the master and shut down the older
    database instance.  Such a switch-over results in only several seconds
    of downtime for an upgrade.
   

diff --git a/doc/src/sgml/dblink.sgml b/doc/src/sgml/dblink.sgml
index d90ea59982b2a60985c61170225cf646bd4c00d5..81f23a28f3fd6f24568360cc2552cda0fa66ef10 100644 (file)
--- a/doc/src/sgml/dblink.sgml
+++ b/doc/src/sgml/dblink.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  dblink
@@ -623,7 +623,7 @@ SELECT *
    Example
 
    
- select dblink_connect('dbname=dblink_test_slave');
+ select dblink_connect('dbname=dblink_test_standby');
   dblink_connect
  ----------------
   OK

diff --git a/doc/src/sgml/external-projects.sgml b/doc/src/sgml/external-projects.sgml
index bcc2e018cd049daa828cb97294ebb8d8a2976acd..7e647cc985952f884bd1ee52274c5c8e89d57802 100644 (file)
--- a/doc/src/sgml/external-projects.sgml
+++ b/doc/src/sgml/external-projects.sgml
@@ -1,4 +1,4 @@
-
+
 
  
   External Projects
@@ -240,7 +240,7 @@
    PostgreSQL replication solutions are developed
    externally. For example,  
    url="http://www.slony.info">Slony-I is a popular
-   master/slave replication solution that is developed independently
+   master/standby replication solution that is developed independently
    from the core project.
   
 


diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml

index 6f2125f2a524cd712bf106252032e133bf451e08..8aa4ecde5f085f7496f5a122a876e28c15b37b05 100644 (file)

--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  High Availability, Load Balancing, and Replication
@@ -161,21 +161,21 @@ protocol to make nodes agree on a serializable transactional order.
   
 
   
-   Trigger-Based Master-Slave Replication
+   Trigger-Based Master-Standby Replication
    
 
     
-     A master-slave replication setup sends all data modification
+     A master-standby replication setup sends all data modification
      queries to the master server.  The master server asynchronously
-     sends data changes to the slave server.  The slave can answer
+     sends data changes to the standby server.  The standby can answer
      read-only queries while the master server is running.  The
-     slave server is ideal for data warehouse queries.
+     standby server is ideal for data warehouse queries.
     
 
     
      Slony-I is an example of this type of replication, with per-table
-     granularity, and support for multiple slaves.  Because it
-     updates the slave server asynchronously (in batches), there is
+     granularity, and support for multiple standby servers.  Because it
+     updates the standby server asynchronously (in batches), there is
      possible data loss during fail over.
     
    
@@ -202,9 +202,9 @@ protocol to make nodes agree on a serializable transactional order.
      this is unacceptable, either the middleware or the application
      must query such values from a single server and then use those
      values in write queries.  Another option is to use this replication
-     option with a traditional master-slave setup, i.e. data modification
+     option with a traditional master-standby setup, i.e. data modification
      queries are sent only to the master and are propagated to the
-     slaves via master-slave replication, not by the replication
+     standby servers via master-standby replication, not by the replication
      middleware.  Care must also be taken that all
      transactions either commit or abort on all servers, perhaps
      using two-phase commit (
@@ -247,7 +247,7 @@ protocol to make nodes agree on a serializable transactional order.
      replication is best for mostly read workloads, though its big
      advantage is that any server can accept write requests —
      there is no need to partition workloads between master and
-     slave servers, and because the data changes are sent from one
+     standby servers, and because the data changes are sent from one
      server to another, there is no problem with non-deterministic
      functions like random().
     
@@ -291,7 +291,7 @@ protocol to make nodes agree on a serializable transactional order.
      Shared Disk Failover
      File System Replication
      Hot/Warm Standby Using PITR
-     Trigger-Based Master-Slave Replication
+     Trigger-Based Master-Standby Replication
      Statement-Based Replication Middleware
      Asynchronous Multimaster Replication
      Synchronous Multimaster Replication
@@ -378,7 +378,7 @@ protocol to make nodes agree on a serializable transactional order.
     
 
     
-     Slaves accept read-only queries
+     Standby accept read-only queries
      
      
      Hot only
@@ -430,7 +430,7 @@ protocol to make nodes agree on a serializable transactional order.
      partitioned by offices, e.g., London and Paris, with a server
      in each office.  If queries combining London and Paris data
      are necessary, an application can query both servers, or
-     master/slave replication can be used to keep a read-only copy
+     master/standby replication can be used to keep a read-only copy
      of the other office's data on each server.
     
    


diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml

index b88833c8ee24d94ed92f7bb2020b64711791883b..dc165f72539edc9d10e8f19ff1fb20c88e834082 100644 (file)

--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Frontend/Backend Protocol
@@ -1315,7 +1315,7 @@ The commands accepted in walsender mode are:
       
        The unique system identifier identifying the cluster. This
        can be used to check that the base backup used to initialize the
-       slave came from the same cluster.
+       standby came from the same cluster.
       
       
       
@@ -1326,7 +1326,7 @@ The commands accepted in walsender mode are:
       
       
       
-       Current TimelineID. Also useful to check that the slave is
+       Current TimelineID. Also useful to check that the standby is
        consistent with the master.
       
       


diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml

index bec6a00084301c6d7a97f01c47f2b4ea57c9d184..8777a2c90403a788b8509807b736fb2c6a85045d 100644 (file)

--- a/doc/src/sgml/release-9.0.sgml
+++ b/doc/src/sgml/release-9.0.sgml
@@ -1,4 +1,4 @@
-
+
 
  
   Release 9.0
@@ -398,7 +398,7 @@ recovery_connections -> hot_standby
       
        Previously WAL files could be sent to standby systems only
        as 16 megabytes files; this allows master changes to be sent to the
-       slave with very little delay. There are new postgresql.conf
+       standby with very little delay. There are new postgresql.conf
        and recovery.conf settings to enable this
        feature, as well as extensive 
        linkend="streaming-replication">documentation.


diff --git a/doc/src/sgml/release-alpha.sgml b/doc/src/sgml/release-alpha.sgml

index 3eb9f6bac69476fc506f3670954dec2dfc13726d..9cc7e8d59f1ef640135bc22f757ce7aa411f185c 100644 (file)

--- a/doc/src/sgml/release-alpha.sgml
+++ b/doc/src/sgml/release-alpha.sgml
@@ -1,4 +1,4 @@
-
+
 
 
   Release 9.0alpha4
@@ -126,7 +126,7 @@
          This implementation should be significantly more
          efficient than the old one, and is also more compatible with
          Hot Standby usage.  There is not yet any facility for HS
-         slaves to receive notifications generated on the master,
+         standby servers to receive notifications generated on the master,
          although such a thing is possible in future.
         
        
@@ -552,7 +552,7 @@
        
         
          Allow read-only connections during recovery, also
-         known as Hot Standby.  This provides a built-in master-slave
+         known as Hot Standby.  This provides a built-in master-standby
          replication solution.
         
        

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 6f2125f2a524cd712bf106252032e133bf451e08..8aa4ecde5f085f7496f5a122a876e28c15b37b05 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  High Availability, Load Balancing, and Replication
@@ -161,21 +161,21 @@ protocol to make nodes agree on a serializable transactional order.
   
 
   
-   Trigger-Based Master-Slave Replication
+   Trigger-Based Master-Standby Replication
    
 
     
-     A master-slave replication setup sends all data modification
+     A master-standby replication setup sends all data modification
      queries to the master server.  The master server asynchronously
-     sends data changes to the slave server.  The slave can answer
+     sends data changes to the standby server.  The standby can answer
      read-only queries while the master server is running.  The
-     slave server is ideal for data warehouse queries.
+     standby server is ideal for data warehouse queries.
     
 
     
      Slony-I is an example of this type of replication, with per-table
-     granularity, and support for multiple slaves.  Because it
-     updates the slave server asynchronously (in batches), there is
+     granularity, and support for multiple standby servers.  Because it
+     updates the standby server asynchronously (in batches), there is
      possible data loss during fail over.
     
    
@@ -202,9 +202,9 @@ protocol to make nodes agree on a serializable transactional order.
      this is unacceptable, either the middleware or the application
      must query such values from a single server and then use those
      values in write queries.  Another option is to use this replication
-     option with a traditional master-slave setup, i.e. data modification
+     option with a traditional master-standby setup, i.e. data modification
      queries are sent only to the master and are propagated to the
-     slaves via master-slave replication, not by the replication
+     standby servers via master-standby replication, not by the replication
      middleware.  Care must also be taken that all
      transactions either commit or abort on all servers, perhaps
      using two-phase commit (
@@ -247,7 +247,7 @@ protocol to make nodes agree on a serializable transactional order.
      replication is best for mostly read workloads, though its big
      advantage is that any server can accept write requests —
      there is no need to partition workloads between master and
-     slave servers, and because the data changes are sent from one
+     standby servers, and because the data changes are sent from one
      server to another, there is no problem with non-deterministic
      functions like random().
     
@@ -291,7 +291,7 @@ protocol to make nodes agree on a serializable transactional order.
      Shared Disk Failover
      File System Replication
      Hot/Warm Standby Using PITR
-     Trigger-Based Master-Slave Replication
+     Trigger-Based Master-Standby Replication
      Statement-Based Replication Middleware
      Asynchronous Multimaster Replication
      Synchronous Multimaster Replication
@@ -378,7 +378,7 @@ protocol to make nodes agree on a serializable transactional order.
     
 
     
-     Slaves accept read-only queries
+     Standby accept read-only queries
      
      
      Hot only
@@ -430,7 +430,7 @@ protocol to make nodes agree on a serializable transactional order.
      partitioned by offices, e.g., London and Paris, with a server
      in each office.  If queries combining London and Paris data
      are necessary, an application can query both servers, or
-     master/slave replication can be used to keep a read-only copy
+     master/standby replication can be used to keep a read-only copy
      of the other office's data on each server.
     
    

diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index b88833c8ee24d94ed92f7bb2020b64711791883b..dc165f72539edc9d10e8f19ff1fb20c88e834082 100644 (file)
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Frontend/Backend Protocol
@@ -1315,7 +1315,7 @@ The commands accepted in walsender mode are:
       
        The unique system identifier identifying the cluster. This
        can be used to check that the base backup used to initialize the
-       slave came from the same cluster.
+       standby came from the same cluster.
       
       
       
@@ -1326,7 +1326,7 @@ The commands accepted in walsender mode are:
       
       
       
-       Current TimelineID. Also useful to check that the slave is
+       Current TimelineID. Also useful to check that the standby is
        consistent with the master.
       
       

diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index bec6a00084301c6d7a97f01c47f2b4ea57c9d184..8777a2c90403a788b8509807b736fb2c6a85045d 100644 (file)
--- a/doc/src/sgml/release-9.0.sgml
+++ b/doc/src/sgml/release-9.0.sgml
@@ -1,4 +1,4 @@
-
+
 
  
   Release 9.0
@@ -398,7 +398,7 @@ recovery_connections -> hot_standby
       
        Previously WAL files could be sent to standby systems only
        as 16 megabytes files; this allows master changes to be sent to the
-       slave with very little delay. There are new postgresql.conf
+       standby with very little delay. There are new postgresql.conf
        and recovery.conf settings to enable this
        feature, as well as extensive 
        linkend="streaming-replication">documentation.


diff --git a/doc/src/sgml/release-alpha.sgml b/doc/src/sgml/release-alpha.sgml

index 3eb9f6bac69476fc506f3670954dec2dfc13726d..9cc7e8d59f1ef640135bc22f757ce7aa411f185c 100644 (file)

--- a/doc/src/sgml/release-alpha.sgml
+++ b/doc/src/sgml/release-alpha.sgml
@@ -1,4 +1,4 @@
-
+
 
 
   Release 9.0alpha4
@@ -126,7 +126,7 @@
          This implementation should be significantly more
          efficient than the old one, and is also more compatible with
          Hot Standby usage.  There is not yet any facility for HS
-         slaves to receive notifications generated on the master,
+         standby servers to receive notifications generated on the master,
          although such a thing is possible in future.
         
        
@@ -552,7 +552,7 @@
        
         
          Allow read-only connections during recovery, also
-         known as Hot Standby.  This provides a built-in master-slave
+         known as Hot Standby.  This provides a built-in master-standby
          replication solution.
         
        

diff --git a/doc/src/sgml/release-alpha.sgml b/doc/src/sgml/release-alpha.sgml
index 3eb9f6bac69476fc506f3670954dec2dfc13726d..9cc7e8d59f1ef640135bc22f757ce7aa411f185c 100644 (file)
--- a/doc/src/sgml/release-alpha.sgml
+++ b/doc/src/sgml/release-alpha.sgml
@@ -1,4 +1,4 @@
-
+
 
 
   Release 9.0alpha4
@@ -126,7 +126,7 @@
          This implementation should be significantly more
          efficient than the old one, and is also more compatible with
          Hot Standby usage.  There is not yet any facility for HS
-         slaves to receive notifications generated on the master,
+         standby servers to receive notifications generated on the master,
          although such a thing is possible in future.
         
        
@@ -552,7 +552,7 @@
        
         
          Allow read-only connections during recovery, also
-         known as Hot Standby.  This provides a built-in master-slave
+         known as Hot Standby.  This provides a built-in master-standby
          replication solution.