Re: 10 beta docs: different replication solutions

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Steve Singer <steve(at)ssinger(dot)info>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 10 beta docs: different replication solutions
Date: 2017-07-31 13:00:43
Message-ID: CAHyXU0zot=ZYhvNA0bDxXRdCPbih+R23zMYmo+7-CoKu5skDsQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 30, 2017 at 8:34 PM, Steve Singer <steve(at)ssinger(dot)info> wrote:
>
> We don't seem to describe logical replication on
>
> https://www.postgresql.org/docs/10/static/different-replication-solutions.html
>
> The attached patch adds a section.

This is a good catch. Two quick observations:

1) Super pedantic point. I don't like the 'repl.' abbreviation in the
'most common implementation' both for the existing hs/sr and for the
newly added logical.

2) This lingo:
+ Logical replication allows the data changes from individual tables
+ to be replicated. Logical replication doesn't require a particular server
+ to be designated as a master or a slave but allows data to flow
in multiple
+ directions. For more information on logical replication, see
<xref linkend="logical-replication">.

Is good, but I would revise it just a bit to emphasize the
subscription nature of logical replication to link the concepts
expressed strongly in the main section. For example:

Logical replication allows the data changes [remove: "from individual
tables to be replicated"] to be published to subscriber nodes. Data
can flow in any direction between nodes on a per-table basis; there is
no concept of a master server. Conflict resolution must be handled
completely by the application. For more information on...

what do you think?

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-07-31 13:07:22 Re: Partition-wise join for join between (declaratively) partitioned tables
Previous Message Peter Moser 2017-07-31 12:53:50 Re: [PROPOSAL] Temporal query processing with range types