</term>

<listitem>

<para>

Specifies acomma-separatedlist of standby names that can support

Specifies a list of standby names that can support

<firstterm>synchronous replication</>, as described in

<xref linkend="synchronous-replication">.

At any one time therewill beat most one active synchronousstandby;

Therewill beone or more active synchronousstandbys;

transactions waiting for commit will be allowed to proceed after

this standby server confirms receipt of their data.

The synchronous standby will be the first standby named in this list

these standby servers confirm receipt of their data.

The synchronous standbys will be those whose names appear

earlier in this list, and

that is both currently connected and streaming data in real-time

(as shown by a state of <literal>streaming</literal> in the

<link linkend="monitoring-stats-views-table">

<literal>pg_stat_replication</></link> view).

Other standby servers appearing later in this list represent potential

synchronous standbys.

If the current synchronous standby disconnects for whatever reason,

synchronous standbys. If any of the current synchronous

standbys disconnects for whatever reason,

it will be replaced immediately with the next-highest-priority standby.

Specifying more than one standby name can allow very high availability.

</para>

<para>

This parameter specifies a list of standby servers by using

either of the following syntaxes:

<synopsis>

<replaceable class="parameter">num_sync</replaceable> ( <replaceable class="parameter">standby_name</replaceable> [, ...] )

<replaceable class="parameter">standby_name</replaceable> [, ...]

</synopsis>

where <replaceable class="parameter">num_sync</replaceable> is

the number of synchronous standbys that transactions need to

wait for replies from,

and <replaceable class="parameter">standby_name</replaceable>

is the name of a standby server. For example, a setting of

<literal>'3 (s1, s2, s3, s4)'</> makes transaction commits wait

until their WAL records are received by three higher priority standbys

chosen from standby servers <literal>s1</>, <literal>s2</>,

<literal>s3</> and <literal>s4</>.

</para>

<para>

The second syntax was used before <productname>PostgreSQL</>

version 9.6 and is still supported. It's the same as the first syntax

with <replaceable class="parameter">num_sync</replaceable>=1.

For example, both settings of <literal>'1 (s1, s2)'</> and

<literal>'s1, s2'</> have the same meaning; either <literal>s1</>

or <literal>s2</> is chosen as a synchronous standby.

</para>

<para>

The name of a standby server for this purpose is the

<varname>application_name</> setting of the standby, as set in the

<varname>primary_conninfo</> of the standby's WAL receiver. There is

no mechanism to enforce uniqueness. In case of duplicates one of the

matching standbys will bechosen to be the synchronous standby, though

matching standbys will beconsidered as higher priority, though

exactly which one is indeterminate.

The special entry <literal>*</> matches any

<varname>application_name</>, including the default application name

of <literal>walreceiver</>.

</para>

<note>

<para>

The <replaceable class="parameter">standby_name</replaceable>

must be enclosed in double quotes if a comma (<literal>,</>),

a double quote (<literal>"</>), <!-- " font-lock sanity -->

a left parentheses (<literal>(</>), a right parentheses (<literal>)</>)

or a space is used in the name of a standby server.

</para>

</note>

<para>

If no synchronous standby names are specified here, then synchronous

replication is not enabled and transaction commits will not wait for

<para>

Synchronous replication offers the ability to confirm that all changes

made by a transaction have been transferred to onesynchronous standby

server. This extendsthe standard level of durability

made by a transaction have been transferred to oneor more synchronous

standby servers. This extendsthat standard level of durability

offered by a transaction commit. This level of protection is referred

to as 2-safe replication in computer science theory.

to as 2-safe replication in computer science theory, and group-1-safe

(group-safe and 1-safe) when <varname>synchronous_commit</> is set to

<literal>remote_write</>.

</para>

<para>

In the case that <varname>synchronous_commit</> is set to

<literal>remote_apply</>, the standby sends reply messages when the commit

record is replayed, making the transaction visible.

If the standby isthe first matchingstandby,as specified in

<varname>synchronous_standby_names</> on the primary, the reply

If the standby ischosen as the synchronousstandby,from a priority

list of<varname>synchronous_standby_names</> on the primary, the reply

messages from that standby will be used to wake users waiting for

confirmation that the commit record has been received. These parameters

allow the administrator to specify which standby servers should be

</sect3>

<sect3 id="synchronous-replication-multiple-standbys">

<title>Multiple Synchronous Standbys</title>

<para>

Synchronous replication supports one or more synchronous standby servers;

transactions will wait until all the standby servers which are considered

as synchronous confirm receipt of their data. The number of synchronous

standbys that transactions must wait for replies from is specified in

<varname>synchronous_standby_names</>. This parameter also specifies

a list of standby names, which determines the priority of each standby

for being chosen as a synchronous standby. The standbys whose names

appear earlier in the list are given higher priority and will be considered

as synchronous. Other standby servers appearing later in this list

represent potential synchronous standbys. If any of the current

synchronous standbys disconnects for whatever reason, it will be replaced

immediately with the next-highest-priority standby.

</para>

<para>

An example of <varname>synchronous_standby_names</> for multiple

synchronous standbys is:

<programlisting>

synchronous_standby_names = '2 (s1, s2, s3)'

</programlisting>

In this example, if four standby servers <literal>s1</>, <literal>s2</>,

<literal>s3</> and <literal>s4</> are running, the two standbys

<literal>s1</> and <literal>s2</> will be chosen as synchronous standbys

because their names appear early in the list of standby names.

<literal>s3</> is a potential synchronous standby and will take over

the role of synchronous standby when either of <literal>s1</> or

<literal>s2</> fails. <literal>s4</> is an asynchronous standby since

its name is not in the list.

</para>

</sect3>

<sect3 id="synchronous-replication-performance">

<title>Planning for Performance</title>

<title>Planning for High Availability</title>

<para>

Commits made when <varname>synchronous_commit</> is set to <literal>on</>,

<literal>remote_apply</> or <literal>remote_write</> will wait until the

synchronous standby responds. The response may never occur if the last, or

only, standby should crash.

<varname>synchronous_standby_names</> specifies the number and

names of synchronous standbys that transaction commits made when

<varname>synchronous_commit</> is set to <literal>on</>,

<literal>remote_apply</> or <literal>remote_write</> will wait for

responses from. Such transaction commits may never be completed

if any one of synchronous standbys should crash.

</para>

<para>

The best solution foravoiding data lossis to ensure youdon't lose

your last remaining synchronous standby. This can be achieved by naming multiple

The best solution forhigh availabilityis to ensure youkeep as many

synchronous standbys as requested. This can be achieved by naming multiple

potential synchronous standbys using <varname>synchronous_standby_names</>.

Thefirst named standby will be used asthesynchronous standby. Standbys

listed afterthis will take over the role of synchronous standby if the

firstone should fail.

Thestandbys whose names appear earlier inthelist will be used as

synchronous standbys. Standbyslisted afterthese will take over

the role of synchronous standby ifone of current ones should fail.

</para>

<para>

they show as committed on the primary. The guarantee we offer is that

the application will not receive explicit acknowledgement of the

successful commit of a transaction until the WAL data is known to be

safely received by thestandby.

safely received byallthesynchronous standbys.

</para>

<para>

If you really do lose your last standby server then you should disable

<varname>synchronous_standby_names</> and reload the configuration file

on the primary server.

If you really cannot keep as many synchronous standbys as requested

then you should decrease the number of synchronous standbys that

transaction commits must wait for responses from

in <varname>synchronous_standby_names</> (or disable it) and

reload the configuration file on the primary server.

</para>

<para>

$(MAKE) -C parsergram.c gram.h scan.c

$(MAKE) -C bootstrapbootparse.c bootscanner.c

$(MAKE) -C catalogschemapg.h postgres.bki postgres.description postgres.shdescription

$(MAKE) -C replicationrepl_gram.c repl_scanner.c

$(MAKE) -C replicationrepl_gram.c repl_scanner.c syncrep_gram.c syncrep_scanner.c

$(MAKE) -C storage/lmgrlwlocknames.h

$(MAKE) -C utilsfmgrtab.c fmgroids.h errcodes.h

$(MAKE) -C utils/miscguc-file.c

catalog/postgres.shdescription\

replication/repl_gram.c\

replication/repl_scanner.c\

replication/syncrep_gram.c\

replication/syncrep_scanner.c\

storage/lmgr/lwlocknames.c\

storage/lmgr/lwlocknames.h\

utils/fmgroids.h\

/repl_gram.c

/repl_scanner.c

/syncrep_gram.c

/syncrep_scanner.c

overrideCPPFLAGS := -I. -I$(srcdir)$(CPPFLAGS)

OBJS = walsender.o walreceiverfuncs.o walreceiver.o basebackup.o\

repl_gram.o slot.o slotfuncs.o syncrep.o

repl_gram.o slot.o slotfuncs.o syncrep.o syncrep_gram.o

SUBDIRS = logical

repl_gram.o: repl_scanner.c

syncrep_gram.o: syncrep_scanner.c

syncrep_scanner.c: FLEXFLAGS = -CF -p

syncrep_scanner.c: FLEX_NO_BACKUP=yes