Thread: [HACKERS] 10 beta docs: different replication solutions
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. Steve
On Sun, Jul 30, 2017 at 8:34 PM, Steve Singer <steve@ssinger.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
On Mon, 31 Jul 2017, Merlin Moncure wrote: > On Sun, Jul 30, 2017 at 8:34 PM, Steve Singer <steve@ssinger.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. Updated > > 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? Sounds good. I've incorporated these changes into an updated patch but I changed the language around conflict resolution. Conflict resolution could be handled by triggers or adding extra columns to the primary key, that wouldn't be 'completely by the application' > > merlin >
On 7/30/17 21:34, Steve Singer 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. Committed with some further tweaking, thanks! -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services