Commit9d90e2b

Amit Kapila

committed

Doc: Fix the ambiguity in the description of failover slots.

The failover slots ensure a seamless transition of a subscriber after thestandby is promoted. But the docs for it also explain the behavior ofasynchronous replication which can confuse the readers.Reported-by: Masahiro IkedaBackpatch-through: 17Discussion:https://postgr.es/m/OS3PR01MB6390B660F4198BB9745E0526B18B2@OS3PR01MB6390.jpnprd01.prod.outlook.com

1 parent6654bb9 commit9d90e2bCopy full SHA for 9d90e2b

File tree

-5

lines changed

-5

lines changed

Lines changed: 2 additions & 5 deletions

Original file line number	Diff line number	Diff line change
`@@ -701,10 +701,7 @@ ALTER SUBSCRIPTION`
`701`	`701`	`<link linkend="sql-createsubscription-params-with-failover"><literal>failover</literal></link>`
`702`	`702`	`parameter ensures a seamless transition of those subscriptions after the`
`703`	`703`	`standby is promoted. They can continue subscribing to publications on the`
`704`		`- new primary server without losing data. Note that in the case of`
`705`		`- asynchronous replication, there remains a risk of data loss for transactions`
`706`		`- committed on the former primary server but have yet to be replicated to the new`
`707`		`- primary server.`
	`704`	`+ new primary server.`
`708`	`705`	`</para>`
`709`	`706`
`710`	`707`	`<para>`
`@@ -791,7 +788,7 @@ test_standby=# SELECT slot_name, (synced AND NOT temporary AND NOT conflicting)`
`791`	`788`	`If all the slots are present on the standby server and the result`
`792`	`789`	`(<literal>failover_ready</literal>) of the above SQL query is true, then`
`793`	`790`	`existing subscriptions can continue subscribing to publications now on the`
`794`		`- new primary server without losing data.`
	`791`	`+ new primary server.`
`795`	`792`	`</para>`
`796`	`793`
`797`	`794`	`</sect1>`

Comments

(0)