pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedUse of term Master/Slave
11+ messages / 10 participants
[nested] [flat]
* Use of term Master/Slave
@ 2017-07-31 21:13 sabrina.iqbal@target.com
0 siblings, 3 replies; 11+ messages in thread
From: sabrina.iqbal@target.com @ 2017-07-31 21:13 UTC (permalink / raw)
To: pgsql-docs
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html
Description:
Wondering why PostgreSQL still uses the terms master and slave when there
are other terms like primary/secondary that can be used in the same manner.
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Use of term Master/Slave
@ 2017-08-01 17:33 Andres Freund <andres@anarazel.de>
parent: sabrina.iqbal@target.com
2 siblings, 1 reply; 11+ messages in thread
From: Andres Freund @ 2017-08-01 17:33 UTC (permalink / raw)
To: sabrina.iqbal@target.com; +Cc: pgsql-docs
Hi,
On 2017-07-31 21:13:48 +0000, sabrina.iqbal@target.com wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html
> Description:
>
> Wondering why PostgreSQL still uses the terms master and slave when there
> are other terms like primary/secondary that can be used in the same manner.
Yea, I think we should be more careful from now on. I think several
people already try, but it's not been a concerted effort so far. I'm
not convinced it's a good idea to change old release notes though.
- Andres
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Use of term Master/Slave
@ 2017-08-01 19:41 Simon Riggs <simon@2ndquadrant.com>
parent: sabrina.iqbal@target.com
2 siblings, 3 replies; 11+ messages in thread
From: Simon Riggs @ 2017-08-01 19:41 UTC (permalink / raw)
To: sabrina.iqbal@target.com; +Cc: pgsql-docs
On 31 July 2017 at 22:13, <sabrina.iqbal@target.com> wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html
> Description:
>
> Wondering why PostgreSQL still uses the terms master and slave when there
> are other terms like primary/secondary that can be used in the same manner.
Do you think primary/secondary is more descriptive?
I started using the terms Primary and Secondary in the original use,
but I think we've moved away from that towards Master/Standby, which
fits better with a world where "muti-master" is a frequently used term
and an eventual goal in core. Multi-primary doesn't seem to make much
sense.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Use of term Master/Slave
@ 2017-08-01 19:52 Joshua D. Drake <jd@commandprompt.com>
parent: Simon Riggs <simon@2ndquadrant.com>
2 siblings, 0 replies; 11+ messages in thread
From: Joshua D. Drake @ 2017-08-01 19:52 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; sabrina.iqbal@target.com; +Cc: pgsql-docs
On 08/01/2017 12:41 PM, Simon Riggs wrote:
> On 31 July 2017 at 22:13, <sabrina.iqbal@target.com> wrote:
>> The following documentation comment has been logged on the website:
>>
>> Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html
>> Description:
>>
>> Wondering why PostgreSQL still uses the terms master and slave when there
>> are other terms like primary/secondary that can be used in the same manner.
>
> Do you think primary/secondary is more descriptive?
I don't, especially when you take into account cascading replication. If
we are going to change these terms we may want to look at the old slony
(and new logical replication) terms such as Origin and Subscriber.
Thanks,
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
***** Unless otherwise stated, opinions are my own. *****
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Use of term Master/Slave
@ 2017-08-01 19:53 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Simon Riggs <simon@2ndquadrant.com>
2 siblings, 1 reply; 11+ messages in thread
From: Alvaro Herrera @ 2017-08-01 19:53 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: sabrina.iqbal@target.com; pgsql-docs
Simon Riggs wrote:
> On 31 July 2017 at 22:13, <sabrina.iqbal@target.com> wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html
> > Description:
> >
> > Wondering why PostgreSQL still uses the terms master and slave when there
> > are other terms like primary/secondary that can be used in the same manner.
>
> Do you think primary/secondary is more descriptive?
I think "primary" is fine, but "secondary" isn't.
> I started using the terms Primary and Secondary in the original use,
> but I think we've moved away from that towards Master/Standby, which
> fits better with a world where "muti-master" is a frequently used term
> and an eventual goal in core. Multi-primary doesn't seem to make much
> sense.
Elsewhere we've started using the terms "origin" and "replica".
"Multi-origin" sounds sensible enough to me whereas "multi-primary"
doesn't.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Use of term Master/Slave
@ 2017-08-01 19:59 Stephen Frost <sfrost@snowman.net>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 1 reply; 11+ messages in thread
From: Stephen Frost @ 2017-08-01 19:59 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; sabrina.iqbal@target.com; pgsql-docs
Alvaro, all,
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Simon Riggs wrote:
> > On 31 July 2017 at 22:13, <sabrina.iqbal@target.com> wrote:
> > > The following documentation comment has been logged on the website:
> > >
> > > Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html
> > > Description:
> > >
> > > Wondering why PostgreSQL still uses the terms master and slave when there
> > > are other terms like primary/secondary that can be used in the same manner.
> >
> > Do you think primary/secondary is more descriptive?
>
> I think "primary" is fine, but "secondary" isn't.
>
> > I started using the terms Primary and Secondary in the original use,
> > but I think we've moved away from that towards Master/Standby, which
> > fits better with a world where "muti-master" is a frequently used term
> > and an eventual goal in core. Multi-primary doesn't seem to make much
> > sense.
>
> Elsewhere we've started using the terms "origin" and "replica".
> "Multi-origin" sounds sensible enough to me whereas "multi-primary"
> doesn't.
I don't feel like we see much of that terminology being used, whereas
'primary' and 'replica' seem to be more common (particularly since
that's what the big O company uses).
Multi-origin doesn't "feel" any better to me than multi-primary does
(neither is great...), but when it comes to the logical replication side
of things, publishers and subscribers does seem to fit well and so I'm
not entirely sure that we actually need to use the terms "multi-primary"
or "multi-origin"..?
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Use of term Master/Slave
@ 2017-08-01 20:38 Jonathan Katz <jonathan.katz@excoventures.com>
parent: Stephen Frost <sfrost@snowman.net>
0 siblings, 0 replies; 11+ messages in thread
From: Jonathan Katz @ 2017-08-01 20:38 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Simon Riggs <simon@2ndquadrant.com>; sabrina.iqbal@target.com; pgsql-docs
> On Aug 1, 2017, at 3:59 PM, Stephen Frost <sfrost@snowman.net> wrote:
>
> Alvaro, all,
>
> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
>> Simon Riggs wrote:
>>> On 31 July 2017 at 22:13, <sabrina.iqbal@target.com> wrote:
>>>> The following documentation comment has been logged on the website:
>>>>
>>>> Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html
>>>> Description:
>>>>
>>>> Wondering why PostgreSQL still uses the terms master and slave when there
>>>> are other terms like primary/secondary that can be used in the same manner.
>>>
>>> Do you think primary/secondary is more descriptive?
>>
>> I think "primary" is fine, but "secondary" isn't.
>>
>>> I started using the terms Primary and Secondary in the original use,
>>> but I think we've moved away from that towards Master/Standby, which
>>> fits better with a world where "muti-master" is a frequently used term
>>> and an eventual goal in core. Multi-primary doesn't seem to make much
>>> sense.
>>
>> Elsewhere we've started using the terms "origin" and "replica".
>> "Multi-origin" sounds sensible enough to me whereas "multi-primary"
>> doesn't.
>
> I don't feel like we see much of that terminology being used, whereas
> 'primary' and 'replica' seem to be more common (particularly since
> that's what the big O company uses).
+1
> Multi-origin doesn't "feel" any better to me than multi-primary does
> (neither is great...), but when it comes to the logical replication side
> of things, publishers and subscribers does seem to fit well and so I'm
> not entirely sure that we actually need to use the terms "multi-primary"
> or "multi-origin"..?
For the type of things logical replication does, publisher / subscriber does seem to be the accepted terminology. We just need to be careful in our own documentation based on the LISTEN / NOTIFY functionality that also has similar subscribe / publish terminology in the industry.
Jonathan
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Use of term Master/Slave
@ 2017-08-01 23:26 Mike Toews <mwtoews@gmail.com>
parent: sabrina.iqbal@target.com
2 siblings, 0 replies; 11+ messages in thread
From: Mike Toews @ 2017-08-01 23:26 UTC (permalink / raw)
To: sabrina.iqbal@target.com; +Cc: pgsql-docs
On 1 August 2017 at 09:13, <sabrina.iqbal@target.com> wrote:
> Wondering why PostgreSQL still uses the terms master and slave when there
> are other terms like primary/secondary that can be used in the same manner.
Another alternative I've seen in different fields is "manager" and "agent".
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Use of term Master/Slave
@ 2017-08-02 07:28 Jürgen Purtz <juergen@purtz.de>
parent: Simon Riggs <simon@2ndquadrant.com>
2 siblings, 0 replies; 11+ messages in thread
From: Jürgen Purtz @ 2017-08-02 07:28 UTC (permalink / raw)
To: pgsql-docs
On 01.08.2017 21:41, Simon Riggs wrote:
> Do you think primary/secondary is more descriptive?
>
> I started using the terms Primary and Secondary in the original use,
> but I think we've moved away from that towards Master/Standby, which
> fits better with a world where "muti-master" is a frequently used term
> and an eventual goal in core. Multi-primary doesn't seem to make much
> sense.
We are not only missing a consensus about the terms noted here. There is
a bunch of terms where it is unclear which one is the 'official' or
'preferred' one. Two additional examples:
WAL / transaction logfile / XLOG file / log segment file / WAL
segment file
Log record / log entry
And there is a second problem: We have a common understanding of terms
like "cluster" or "database". But people coming from other DBMS may have
a different understanding.
A new PG user easily gets lost in the "term-jungle" used in our
documentation, in PG related books, blogs, and training material.
My proposal is to add an additional appendix to our documentation, where
fundamental terms and there meaning for the PG community are defined in
short and clear words (after we have found a consensus about them).
Jürgen Purtz
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: Use of term Master/Slave
@ 2017-08-07 21:46 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 11+ messages in thread
From: Peter Eisentraut @ 2017-08-07 21:46 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; sabrina.iqbal@target.com; +Cc: pgsql-docs
On 8/1/17 13:33, Andres Freund wrote:
> On 2017-07-31 21:13:48 +0000, sabrina.iqbal@target.com wrote:
>> The following documentation comment has been logged on the website:
>>
>> Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html
>> Description:
>>
>> Wondering why PostgreSQL still uses the terms master and slave when there
>> are other terms like primary/secondary that can be used in the same manner.
>
> Yea, I think we should be more careful from now on. I think several
> people already try, but it's not been a concerted effort so far.
Here is a patch to remove remaining uses of "slave" in replication contexts.
Remaining uses are in the Tcl API, which we can't do anything about, and
in a plpgsql test, where it is used for foreign key relationships. (I'm
not sure what the use in the dblink test that I patched was meant for,
so I just removed it.) Old release notes are not touched.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Attachments:
0001-Remove-uses-of-slave-in-replication-contexts.patch (text/plain, 29.4K) download
From 5cec779d62c9a4e3cf8ff6c5d7a825301ca03ada Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 7 Aug 2017 17:42:47 -0400
Subject: [PATCH] Remove uses of "slave" in replication contexts
This affects mostly code comments, some documentation, and tests.
Official APIs already used "standby".
---
contrib/dblink/expected/dblink.out | 6 +-
contrib/dblink/sql/dblink.sql | 6 +-
doc/src/sgml/high-availability.sgml | 2 +-
doc/src/sgml/ref/pgupgrade.sgml | 4 +-
src/backend/access/transam/commit_ts.c | 2 +-
src/backend/access/transam/multixact.c | 2 +-
src/backend/access/transam/varsup.c | 4 +-
src/backend/catalog/namespace.c | 4 +-
src/backend/commands/variable.c | 4 +-
src/backend/executor/execMain.c | 4 +-
src/backend/replication/walsender.c | 2 +-
src/backend/storage/ipc/procarray.c | 2 +-
src/backend/tcop/utility.c | 2 +-
src/bin/pg_dump/pg_dump.c | 2 +-
src/bin/pg_rewind/RewindTest.pm | 2 +-
src/test/modules/commit_ts/t/002_standby.pl | 4 +-
src/test/modules/commit_ts/t/003_standby_2.pl | 2 +-
src/test/recovery/t/002_archiving.pl | 2 +-
src/test/recovery/t/005_replay_delay.pl | 2 +-
src/test/recovery/t/009_twophase.pl | 86 +++++++++++++--------------
src/test/recovery/t/012_subtransactions.pl | 62 +++++++++----------
21 files changed, 103 insertions(+), 103 deletions(-)
diff --git a/contrib/dblink/expected/dblink.out b/contrib/dblink/expected/dblink.out
index 4b6d26e574..511691e57f 100644
--- a/contrib/dblink/expected/dblink.out
+++ b/contrib/dblink/expected/dblink.out
@@ -270,7 +270,7 @@ SELECT *
FROM dblink('SELECT * FROM foo') AS t(a int, b text, c text[])
WHERE t.a > 7;
ERROR: connection not available
--- put more data into our slave table, first using arbitrary connection syntax
+-- put more data into our table, first using arbitrary connection syntax
-- but truncate the actual return value so we can use diff to check for success
SELECT substr(dblink_exec(connection_parameters(),'INSERT INTO foo VALUES(10,''k'',''{"a10","b10","c10"}'')'),1,6);
substr
@@ -285,7 +285,7 @@ SELECT dblink_connect(connection_parameters());
OK
(1 row)
--- put more data into our slave table, using persistent connection syntax
+-- put more data into our table, using persistent connection syntax
-- but truncate the actual return value so we can use diff to check for success
SELECT substr(dblink_exec('INSERT INTO foo VALUES(11,''l'',''{"a11","b11","c11"}'')'),1,6);
substr
@@ -610,7 +610,7 @@ SELECT dblink_connect('myconn',connection_parameters());
OK
(1 row)
--- put more data into our slave table, using named persistent connection syntax
+-- put more data into our table, using named persistent connection syntax
-- but truncate the actual return value so we can use diff to check for success
SELECT substr(dblink_exec('myconn','INSERT INTO foo VALUES(11,''l'',''{"a11","b11","c11"}'')'),1,6);
substr
diff --git a/contrib/dblink/sql/dblink.sql b/contrib/dblink/sql/dblink.sql
index 681cf6a6e8..b093fa6722 100644
--- a/contrib/dblink/sql/dblink.sql
+++ b/contrib/dblink/sql/dblink.sql
@@ -160,14 +160,14 @@ CREATE FUNCTION connection_parameters() RETURNS text LANGUAGE SQL AS $f$
FROM dblink('SELECT * FROM foo') AS t(a int, b text, c text[])
WHERE t.a > 7;
--- put more data into our slave table, first using arbitrary connection syntax
+-- put more data into our table, first using arbitrary connection syntax
-- but truncate the actual return value so we can use diff to check for success
SELECT substr(dblink_exec(connection_parameters(),'INSERT INTO foo VALUES(10,''k'',''{"a10","b10","c10"}'')'),1,6);
-- create a persistent connection
SELECT dblink_connect(connection_parameters());
--- put more data into our slave table, using persistent connection syntax
+-- put more data into our table, using persistent connection syntax
-- but truncate the actual return value so we can use diff to check for success
SELECT substr(dblink_exec('INSERT INTO foo VALUES(11,''l'',''{"a11","b11","c11"}'')'),1,6);
@@ -316,7 +316,7 @@ CREATE FUNCTION connection_parameters() RETURNS text LANGUAGE SQL AS $f$
-- create a named persistent connection
SELECT dblink_connect('myconn',connection_parameters());
--- put more data into our slave table, using named persistent connection syntax
+-- put more data into our table, using named persistent connection syntax
-- but truncate the actual return value so we can use diff to check for success
SELECT substr(dblink_exec('myconn','INSERT INTO foo VALUES(11,''l'',''{"a11","b11","c11"}'')'),1,6);
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 138bdf2a75..a4494a3494 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -40,7 +40,7 @@ <title>High Availability, Load Balancing, and Replication</title>
server to modify the data. Servers that can modify data are
called read/write, <firstterm>master</> or <firstterm>primary</> servers.
Servers that track changes in the master are called <firstterm>standby</>
- or <firstterm>slave</> servers. A standby server that cannot be connected
+ or <firstterm>secondary</> servers. A standby server that cannot be connected
to until it is promoted to a master server is called a <firstterm>warm
standby</> server, and one that can accept connections and serves read-only
queries is called a <firstterm>hot standby</> server.
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index ac7ec9f23c..d44431803b 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -483,7 +483,7 @@ <title>Run <application>rsync</></title>
<para>
From a directory that is above the old and new database cluster
- directories, run this for each slave:
+ directories, run this for each standby:
<programlisting>
rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir
@@ -517,7 +517,7 @@ <title>Configure streaming replication and log-shipping standby servers</title>
<para>
Configure the servers for log shipping. (You do not need to run
<function>pg_start_backup()</> and <function>pg_stop_backup()</>
- or take a file system backup as the slaves are still synchronized
+ or take a file system backup as the standbys are still synchronized
with the master.)
</para>
</step>
diff --git a/src/backend/access/transam/commit_ts.c b/src/backend/access/transam/commit_ts.c
index 827d976db8..60fb9eeb06 100644
--- a/src/backend/access/transam/commit_ts.c
+++ b/src/backend/access/transam/commit_ts.c
@@ -621,7 +621,7 @@ CommitTsParameterChange(bool newvalue, bool oldvalue)
*
* The reason why this SLRU needs separate activation/deactivation functions is
* that it can be enabled/disabled during start and the activation/deactivation
- * on master is propagated to slave via replay. Other SLRUs don't have this
+ * on master is propagated to standby via replay. Other SLRUs don't have this
* property and they can be just initialized during normal startup.
*
* This is in charge of creating the currently active segment, if it's not
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 682eef420b..7142ecede0 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -939,7 +939,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
debug_elog3(DEBUG2, "GetNew: for %d xids", nmembers);
- /* safety check, we should never get this far in a HS slave */
+ /* safety check, we should never get this far in a HS standby */
if (RecoveryInProgress())
elog(ERROR, "cannot assign MultiXactIds during recovery");
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 15e05591b7..702c8c957f 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -67,7 +67,7 @@ GetNewTransactionId(bool isSubXact)
return BootstrapTransactionId;
}
- /* safety check, we should never get this far in a HS slave */
+ /* safety check, we should never get this far in a HS standby */
if (RecoveryInProgress())
elog(ERROR, "cannot assign TransactionIds during recovery");
@@ -468,7 +468,7 @@ GetNewObjectId(void)
{
Oid result;
- /* safety check, we should never get this far in a HS slave */
+ /* safety check, we should never get this far in a HS standby */
if (RecoveryInProgress())
elog(ERROR, "cannot assign OIDs during recovery");
diff --git a/src/backend/catalog/namespace.c b/src/backend/catalog/namespace.c
index 029a132bb4..6859a97363 100644
--- a/src/backend/catalog/namespace.c
+++ b/src/backend/catalog/namespace.c
@@ -3802,10 +3802,10 @@ InitTempTableNamespace(void)
get_database_name(MyDatabaseId))));
/*
- * Do not allow a Hot Standby slave session to make temp tables. Aside
+ * Do not allow a Hot Standby session to make temp tables. Aside
* from problems with modifying the system catalogs, there is a naming
* conflict: pg_temp_N belongs to the session with BackendId N on the
- * master, not to a slave session with the same BackendId. We should not
+ * master, not to a hot standby session with the same BackendId. We should not
* be able to get here anyway due to XactReadOnly checks, but let's just
* make real sure. Note that this also backstops various operations that
* allow XactReadOnly transactions to modify temp tables; they'd need
diff --git a/src/backend/commands/variable.c b/src/backend/commands/variable.c
index 4156bcd8df..3ed1c56e82 100644
--- a/src/backend/commands/variable.c
+++ b/src/backend/commands/variable.c
@@ -472,8 +472,8 @@ show_log_timezone(void)
* We allow idempotent changes (r/w -> r/w and r/o -> r/o) at any time, and
* we also always allow changes from read-write to read-only. However,
* read-only may be changed to read-write only when in a top-level transaction
- * that has not yet taken an initial snapshot. Can't do it in a hot standby
- * slave, either.
+ * that has not yet taken an initial snapshot. Can't do it in a hot standby,
+ * either.
*
* If we are not in a transaction at all, just allow the change; it means
* nothing since XactReadOnly will be reset by the next StartTransaction().
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index c11aa4fe21..6671a25ffb 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -759,8 +759,8 @@ ExecCheckRTEPermsModified(Oid relOid, Oid userid, Bitmapset *modifiedCols,
* unless we're in parallel mode, in which case don't even allow writes
* to temp tables.
*
- * Note: in a Hot Standby slave this would need to reject writes to temp
- * tables just as we do in parallel mode; but an HS slave can't have created
+ * Note: in a Hot Standby this would need to reject writes to temp
+ * tables just as we do in parallel mode; but an HS standby can't have created
* any temp tables in the first place, so no need to check that.
*/
static void
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 9a2babef1e..03e1cf44de 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -2572,7 +2572,7 @@ XLogSendPhysical(void)
* fsync'd to disk. We cannot go further than what's been written out
* given the current implementation of XLogRead(). And in any case
* it's unsafe to send WAL that is not securely down to disk on the
- * master: if the master subsequently crashes and restarts, slaves
+ * master: if the master subsequently crashes and restarts, standbys
* must not have applied any WAL that got lost on the master.
*/
SendRqstPtr = GetFlushRecPtr();
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index a7e8cf2d43..eab218e316 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -1408,7 +1408,7 @@ GetOldestXmin(Relation rel, int flags)
* being careful not to generate a "permanent" XID.
*
* vacuum_defer_cleanup_age provides some additional "slop" for the
- * benefit of hot standby queries on slave servers. This is quick and
+ * benefit of hot standby queries on standby servers. This is quick and
* dirty, and perhaps not all that useful unless the master has a
* predictable transaction rate, but it offers some protection when
* there's no walsender connection. Note that we are assuming
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index ddacac8774..775477c6cf 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -264,7 +264,7 @@ PreventCommandIfParallelMode(const char *cmdname)
/*
* PreventCommandDuringRecovery: throw error if RecoveryInProgress
*
- * The majority of operations that are unsafe in a Hot Standby slave
+ * The majority of operations that are unsafe in a Hot Standby
* will be rejected by XactReadOnly tests. However there are a few
* commands that are allowed in "read-only" xacts but cannot be allowed
* in Hot Standby mode. Those commands should call this function.
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 393b9e25a9..37cb7cd986 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -676,7 +676,7 @@ main(int argc, char **argv)
dopt.no_security_labels = 1;
/*
- * On hot standby slaves, never try to dump unlogged table data, since it
+ * On hot standbys, never try to dump unlogged table data, since it
* will just throw an error.
*/
if (fout->isStandby)
diff --git a/src/bin/pg_rewind/RewindTest.pm b/src/bin/pg_rewind/RewindTest.pm
index 39a559e259..6649c22b4f 100644
--- a/src/bin/pg_rewind/RewindTest.pm
+++ b/src/bin/pg_rewind/RewindTest.pm
@@ -160,7 +160,7 @@ sub promote_standby
$node_master->poll_query_until('postgres', $wal_received_query)
or die "Timed out while waiting for standby to receive and write WAL";
- # Now promote slave and insert some new data on master, this will put
+ # Now promote standby and insert some new data on master, this will put
# the master out-of-sync with the standby.
$node_standby->promote;
diff --git a/src/test/modules/commit_ts/t/002_standby.pl b/src/test/modules/commit_ts/t/002_standby.pl
index 1437519aa1..83e851954b 100644
--- a/src/test/modules/commit_ts/t/002_standby.pl
+++ b/src/test/modules/commit_ts/t/002_standby.pl
@@ -34,7 +34,7 @@
$master->safe_psql('postgres', 'select pg_current_wal_lsn()');
$standby->poll_query_until('postgres',
qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_lsn()})
- or die "slave never caught up";
+ or die "standby never caught up";
my $standby_ts = $standby->safe_psql('postgres',
qq{select ts.* from pg_class, pg_xact_commit_timestamp(xmin) ts where relname = 't10'}
@@ -47,7 +47,7 @@
$master_lsn = $master->safe_psql('postgres', 'select pg_current_wal_lsn()');
$standby->poll_query_until('postgres',
qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_lsn()})
- or die "slave never caught up";
+ or die "standby never caught up";
$standby->safe_psql('postgres', 'checkpoint');
# This one should raise an error now
diff --git a/src/test/modules/commit_ts/t/003_standby_2.pl b/src/test/modules/commit_ts/t/003_standby_2.pl
index c3000f5b4c..27494709e1 100644
--- a/src/test/modules/commit_ts/t/003_standby_2.pl
+++ b/src/test/modules/commit_ts/t/003_standby_2.pl
@@ -33,7 +33,7 @@
$master->safe_psql('postgres', 'select pg_current_wal_lsn()');
$standby->poll_query_until('postgres',
qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_lsn()})
- or die "slave never caught up";
+ or die "standby never caught up";
$standby->safe_psql('postgres', 'checkpoint');
$standby->restart;
diff --git a/src/test/recovery/t/002_archiving.pl b/src/test/recovery/t/002_archiving.pl
index 42a9afb2f3..e1bd3c95cc 100644
--- a/src/test/recovery/t/002_archiving.pl
+++ b/src/test/recovery/t/002_archiving.pl
@@ -16,7 +16,7 @@
# Start it
$node_master->start;
-# Take backup for slave
+# Take backup for standby
$node_master->backup($backup_name);
# Initialize standby node from backup, fetching WAL from archives
diff --git a/src/test/recovery/t/005_replay_delay.pl b/src/test/recovery/t/005_replay_delay.pl
index 208b278fcd..8909c4548b 100644
--- a/src/test/recovery/t/005_replay_delay.pl
+++ b/src/test/recovery/t/005_replay_delay.pl
@@ -40,7 +40,7 @@
"INSERT INTO tab_int VALUES (generate_series(11, 20))");
# Now wait for replay to complete on standby. We're done waiting when the
-# slave has replayed up to the previously saved master LSN.
+# standby has replayed up to the previously saved master LSN.
my $until_lsn =
$node_master->safe_psql('postgres', "SELECT pg_current_wal_lsn()");
diff --git a/src/test/recovery/t/009_twophase.pl b/src/test/recovery/t/009_twophase.pl
index d5bcd25fed..1d1dae66f2 100644
--- a/src/test/recovery/t/009_twophase.pl
+++ b/src/test/recovery/t/009_twophase.pl
@@ -23,7 +23,7 @@ sub configure_and_reload
is($psql_out, 't', "reload node $name with $parameter");
}
-# Set up two nodes, which will alternately be master and replication slave.
+# Set up two nodes, which will alternately be master and replication standby.
# Setup london node
my $node_london = get_new_node("london");
@@ -46,9 +46,9 @@ sub configure_and_reload
configure_and_reload($node_london, "synchronous_standby_names = 'paris'");
configure_and_reload($node_paris, "synchronous_standby_names = 'london'");
-# Set up nonce names for current master and slave nodes
-note "Initially, london is master and paris is slave";
-my ($cur_master, $cur_slave) = ($node_london, $node_paris);
+# Set up nonce names for current master and standby nodes
+note "Initially, london is master and paris is standby";
+my ($cur_master, $cur_standby) = ($node_london, $node_paris);
my $cur_master_name = $cur_master->name;
# Create table we'll use in the test transactions
@@ -163,7 +163,7 @@ sub configure_and_reload
$cur_master->psql('postgres', "COMMIT PREPARED 'xact_009_7'");
###############################################################################
-# Check that WAL replay will cleanup its shared memory state on running slave.
+# Check that WAL replay will cleanup its shared memory state on running standby.
###############################################################################
$cur_master->psql(
@@ -174,7 +174,7 @@ sub configure_and_reload
INSERT INTO t_009_tbl VALUES (18, 'issued to ${cur_master_name}');
PREPARE TRANSACTION 'xact_009_8';
COMMIT PREPARED 'xact_009_8';");
-$cur_slave->psql(
+$cur_standby->psql(
'postgres',
"SELECT count(*) FROM pg_prepared_xacts",
stdout => \$psql_out);
@@ -182,7 +182,7 @@ sub configure_and_reload
"Cleanup of shared memory state on running standby without checkpoint");
###############################################################################
-# Same as in previous case, but let's force checkpoint on slave between
+# Same as in previous case, but let's force checkpoint on standby between
# prepare and commit to use on-disk twophase files.
###############################################################################
@@ -193,9 +193,9 @@ sub configure_and_reload
SAVEPOINT s1;
INSERT INTO t_009_tbl VALUES (20, 'issued to ${cur_master_name}');
PREPARE TRANSACTION 'xact_009_9';");
-$cur_slave->psql('postgres', "CHECKPOINT");
+$cur_standby->psql('postgres', "CHECKPOINT");
$cur_master->psql('postgres', "COMMIT PREPARED 'xact_009_9'");
-$cur_slave->psql(
+$cur_standby->psql(
'postgres',
"SELECT count(*) FROM pg_prepared_xacts",
stdout => \$psql_out);
@@ -203,7 +203,7 @@ sub configure_and_reload
"Cleanup of shared memory state on running standby after checkpoint");
###############################################################################
-# Check that prepared transactions can be committed on promoted slave.
+# Check that prepared transactions can be committed on promoted standby.
###############################################################################
$cur_master->psql(
@@ -214,26 +214,26 @@ sub configure_and_reload
INSERT INTO t_009_tbl VALUES (22, 'issued to ${cur_master_name}');
PREPARE TRANSACTION 'xact_009_10';");
$cur_master->teardown_node;
-$cur_slave->promote;
+$cur_standby->promote;
# change roles
-note "Now paris is master and london is slave";
-($cur_master, $cur_slave) = ($node_paris, $node_london);
+note "Now paris is master and london is standby";
+($cur_master, $cur_standby) = ($node_paris, $node_london);
$cur_master_name = $cur_master->name;
# because london is not running at this point, we can't use syncrep commit
# on this command
$psql_rc = $cur_master->psql('postgres',
"SET synchronous_commit = off; COMMIT PREPARED 'xact_009_10'");
-is($psql_rc, '0', "Restore of prepared transaction on promoted slave");
+is($psql_rc, '0', "Restore of prepared transaction on promoted standby");
-# restart old master as new slave
-$cur_slave->enable_streaming($cur_master);
-$cur_slave->append_conf(
+# restart old master as new standby
+$cur_standby->enable_streaming($cur_master);
+$cur_standby->append_conf(
'recovery.conf', qq(
recovery_target_timeline='latest'
));
-$cur_slave->start;
+$cur_standby->start;
###############################################################################
# Check that prepared transactions are replayed after soft restart of standby
@@ -250,12 +250,12 @@ sub configure_and_reload
INSERT INTO t_009_tbl VALUES (24, 'issued to ${cur_master_name}');
PREPARE TRANSACTION 'xact_009_11';");
$cur_master->stop;
-$cur_slave->restart;
-$cur_slave->promote;
+$cur_standby->restart;
+$cur_standby->promote;
# change roles
-note "Now london is master and paris is slave";
-($cur_master, $cur_slave) = ($node_london, $node_paris);
+note "Now london is master and paris is standby";
+($cur_master, $cur_standby) = ($node_london, $node_paris);
$cur_master_name = $cur_master->name;
$cur_master->psql(
@@ -265,18 +265,18 @@ sub configure_and_reload
is($psql_out, '1',
"Restore prepared transactions from files with master down");
-# restart old master as new slave
-$cur_slave->enable_streaming($cur_master);
-$cur_slave->append_conf(
+# restart old master as new standby
+$cur_standby->enable_streaming($cur_master);
+$cur_standby->append_conf(
'recovery.conf', qq(
recovery_target_timeline='latest'
));
-$cur_slave->start;
+$cur_standby->start;
$cur_master->psql('postgres', "COMMIT PREPARED 'xact_009_11'");
###############################################################################
-# Check that prepared transactions are correctly replayed after slave hard
+# Check that prepared transactions are correctly replayed after standby hard
# restart while master is down.
###############################################################################
@@ -289,13 +289,13 @@ sub configure_and_reload
PREPARE TRANSACTION 'xact_009_12';
");
$cur_master->stop;
-$cur_slave->teardown_node;
-$cur_slave->start;
-$cur_slave->promote;
+$cur_standby->teardown_node;
+$cur_standby->start;
+$cur_standby->promote;
# change roles
-note "Now paris is master and london is slave";
-($cur_master, $cur_slave) = ($node_paris, $node_london);
+note "Now paris is master and london is standby";
+($cur_master, $cur_standby) = ($node_paris, $node_london);
$cur_master_name = $cur_master->name;
$cur_master->psql(
@@ -305,13 +305,13 @@ sub configure_and_reload
is($psql_out, '1',
"Restore prepared transactions from records with master down");
-# restart old master as new slave
-$cur_slave->enable_streaming($cur_master);
-$cur_slave->append_conf(
+# restart old master as new standby
+$cur_standby->enable_streaming($cur_master);
+$cur_standby->append_conf(
'recovery.conf', qq(
recovery_target_timeline='latest'
));
-$cur_slave->start;
+$cur_standby->start;
$cur_master->psql('postgres', "COMMIT PREPARED 'xact_009_12'");
@@ -332,7 +332,7 @@ sub configure_and_reload
CHECKPOINT;
COMMIT PREPARED 'xact_009_13';");
-$cur_slave->psql(
+$cur_standby->psql(
'postgres',
"SELECT count(*) FROM t_009_tbl2",
stdout => \$psql_out);
@@ -383,13 +383,13 @@ sub configure_and_reload
is($psql_out, qq{27|issued to paris},
"Check expected t_009_tbl2 data on master");
-$cur_slave->psql(
+$cur_standby->psql(
'postgres',
"SELECT count(*) FROM pg_prepared_xacts",
stdout => \$psql_out);
-is($psql_out, '0', "No uncommitted prepared transactions on slave");
+is($psql_out, '0', "No uncommitted prepared transactions on standby");
-$cur_slave->psql(
+$cur_standby->psql(
'postgres',
"SELECT * FROM t_009_tbl ORDER BY id",
stdout => \$psql_out);
@@ -415,11 +415,11 @@ sub configure_and_reload
24|issued to paris
25|issued to london
26|issued to london},
- "Check expected t_009_tbl data on slave");
+ "Check expected t_009_tbl data on standby");
-$cur_slave->psql(
+$cur_standby->psql(
'postgres',
"SELECT * FROM t_009_tbl2",
stdout => \$psql_out);
is($psql_out, qq{27|issued to paris},
- "Check expected t_009_tbl2 data on slave");
+ "Check expected t_009_tbl2 data on standby");
diff --git a/src/test/recovery/t/012_subtransactions.pl b/src/test/recovery/t/012_subtransactions.pl
index c99733cad7..216c3331d6 100644
--- a/src/test/recovery/t/012_subtransactions.pl
+++ b/src/test/recovery/t/012_subtransactions.pl
@@ -18,11 +18,11 @@
$node_master->backup('master_backup');
$node_master->psql('postgres', "CREATE TABLE t_012_tbl (id int)");
-# Setup slave node
-my $node_slave = get_new_node('slave');
-$node_slave->init_from_backup($node_master, 'master_backup',
+# Setup standby node
+my $node_standby = get_new_node('standby');
+$node_standby->init_from_backup($node_master, 'master_backup',
has_streaming => 1);
-$node_slave->start;
+$node_standby->start;
# Switch to synchronous replication
$node_master->append_conf(
@@ -100,31 +100,31 @@
BEGIN;
SELECT hs_subxids(127);
COMMIT;");
-$node_master->wait_for_catchup($node_slave, 'replay',
+$node_master->wait_for_catchup($node_standby, 'replay',
$node_master->lsn('insert'));
-$node_slave->psql(
+$node_standby->psql(
'postgres',
"SELECT coalesce(sum(id),-1) FROM t_012_tbl",
stdout => \$psql_out);
is($psql_out, '8128', "Visible");
$node_master->stop;
-$node_slave->promote;
+$node_standby->promote;
-$node_slave->psql(
+$node_standby->psql(
'postgres',
"SELECT coalesce(sum(id),-1) FROM t_012_tbl",
stdout => \$psql_out);
is($psql_out, '8128', "Visible");
# restore state
-($node_master, $node_slave) = ($node_slave, $node_master);
-$node_slave->enable_streaming($node_master);
-$node_slave->append_conf(
+($node_master, $node_standby) = ($node_standby, $node_master);
+$node_standby->enable_streaming($node_master);
+$node_standby->append_conf(
'recovery.conf', qq(
recovery_target_timeline='latest'
));
-$node_slave->start;
-$node_slave->psql(
+$node_standby->start;
+$node_standby->psql(
'postgres',
"SELECT coalesce(sum(id),-1) FROM t_012_tbl",
stdout => \$psql_out);
@@ -151,33 +151,33 @@
BEGIN;
SELECT hs_subxids(127);
PREPARE TRANSACTION 'xact_012_1';");
-$node_master->wait_for_catchup($node_slave, 'replay',
+$node_master->wait_for_catchup($node_standby, 'replay',
$node_master->lsn('insert'));
-$node_slave->psql(
+$node_standby->psql(
'postgres',
"SELECT coalesce(sum(id),-1) FROM t_012_tbl",
stdout => \$psql_out);
is($psql_out, '-1', "Not visible");
$node_master->stop;
-$node_slave->promote;
+$node_standby->promote;
-$node_slave->psql(
+$node_standby->psql(
'postgres',
"SELECT coalesce(sum(id),-1) FROM t_012_tbl",
stdout => \$psql_out);
is($psql_out, '-1', "Not visible");
# restore state
-($node_master, $node_slave) = ($node_slave, $node_master);
-$node_slave->enable_streaming($node_master);
-$node_slave->append_conf(
+($node_master, $node_standby) = ($node_standby, $node_master);
+$node_standby->enable_streaming($node_master);
+$node_standby->append_conf(
'recovery.conf', qq(
recovery_target_timeline='latest'
));
-$node_slave->start;
+$node_standby->start;
$psql_rc = $node_master->psql('postgres', "COMMIT PREPARED 'xact_012_1'");
is($psql_rc, '0',
-"Restore of PGPROC_MAX_CACHED_SUBXIDS+ prepared transaction on promoted slave"
+"Restore of PGPROC_MAX_CACHED_SUBXIDS+ prepared transaction on promoted standby"
);
$node_master->psql(
@@ -192,33 +192,33 @@
BEGIN;
SELECT hs_subxids(201);
PREPARE TRANSACTION 'xact_012_1';");
-$node_master->wait_for_catchup($node_slave, 'replay',
+$node_master->wait_for_catchup($node_standby, 'replay',
$node_master->lsn('insert'));
-$node_slave->psql(
+$node_standby->psql(
'postgres',
"SELECT coalesce(sum(id),-1) FROM t_012_tbl",
stdout => \$psql_out);
is($psql_out, '-1', "Not visible");
$node_master->stop;
-$node_slave->promote;
+$node_standby->promote;
-$node_slave->psql(
+$node_standby->psql(
'postgres',
"SELECT coalesce(sum(id),-1) FROM t_012_tbl",
stdout => \$psql_out);
is($psql_out, '-1', "Not visible");
# restore state
-($node_master, $node_slave) = ($node_slave, $node_master);
-$node_slave->enable_streaming($node_master);
-$node_slave->append_conf(
+($node_master, $node_standby) = ($node_standby, $node_master);
+$node_standby->enable_streaming($node_master);
+$node_standby->append_conf(
'recovery.conf', qq(
recovery_target_timeline='latest'
));
-$node_slave->start;
+$node_standby->start;
$psql_rc = $node_master->psql('postgres', "ROLLBACK PREPARED 'xact_012_1'");
is($psql_rc, '0',
-"Rollback of PGPROC_MAX_CACHED_SUBXIDS+ prepared transaction on promoted slave"
+"Rollback of PGPROC_MAX_CACHED_SUBXIDS+ prepared transaction on promoted standby"
);
$node_master->psql(
--
2.14.0
* Re: Use of term Master/Slave
@ 2017-08-11 02:56 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 0 replies; 11+ messages in thread
From: Peter Eisentraut @ 2017-08-11 02:56 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; sabrina.iqbal@target.com; +Cc: pgsql-docs
On 8/7/17 17:46, Peter Eisentraut wrote:
> On 8/1/17 13:33, Andres Freund wrote:
>> On 2017-07-31 21:13:48 +0000, sabrina.iqbal@target.com wrote:
>>> The following documentation comment has been logged on the website:
>>>
>>> Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html
>>> Description:
>>>
>>> Wondering why PostgreSQL still uses the terms master and slave when there
>>> are other terms like primary/secondary that can be used in the same manner.
>>
>> Yea, I think we should be more careful from now on. I think several
>> people already try, but it's not been a concerted effort so far.
>
> Here is a patch to remove remaining uses of "slave" in replication contexts.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2017-08-11 02:56 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-07-31 21:13 Use of term Master/Slave sabrina.iqbal@target.com
2017-08-01 17:33 ` Andres Freund <andres@anarazel.de>
2017-08-07 21:46 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-08-11 02:56 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-08-01 19:41 ` Simon Riggs <simon@2ndquadrant.com>
2017-08-01 19:52 ` Joshua D. Drake <jd@commandprompt.com>
2017-08-01 19:53 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2017-08-01 19:59 ` Stephen Frost <sfrost@snowman.net>
2017-08-01 20:38 ` Jonathan Katz <jonathan.katz@excoventures.com>
2017-08-02 07:28 ` Jürgen Purtz <juergen@purtz.de>
2017-08-01 23:26 ` Mike Toews <mwtoews@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox