Right now, a priority-based sync replication is chosen for keeping backward compatibility. However some hackers argued to change this decision so that a quorum commit is chosen because they think that most users prefer to a quorum.

This is a matter of prioritizing either of service continuity or configuration error detection. Continue considering what to do based on user feedback during beta period, other developers' opinions, and the solution using SQLSTATE.

original commit: 274bb2b3 (principal author: Robert Haas; owner: Robert Haas)

Right now, libpq issues SHOW transaction_read_only upon each connection. This is inefficient, and we should use some GUC_REPORT variable to avoid this round-trip when connecting to PG10 or later. In addition, target_session_attrs=read-only should be available even in PG10 to meet the average expectation.

On Windows, ICU doesn't use sortsupport, even though there is no logical reason for that restriction. This is obviously an artifact of Windows libc. Windows isn't special from the point of view of the new ICU collation provider.

We should consider fixing the issue by converting to and from pg_collation's BCP 47 format to the more widely supported legacy language tag format as needed (a patch to do this is available), and standardizing on ICU collations' pg_collation.collcollate being in BCP 47 format on all ICU version (not just ICU >= 54).

Removing support for ICU versions 4.2 and 4.4 (versions for which support was only added in eccead9, back in August) will simplify resolving this open item. (Technically, we wouldn't even need to change how collcolate canonicalization is performed if we took this approach.)

There will be still many source comments and documentations that we7c030783a5bd07cadffc2a1018bc33119a4c7505 need to update, for example, in high-availability.sgml. We need to check and update them throughly.

The priority value is assigned to each standby listed in s_s_names even in quorum commit though those priority values are not used at all. Users can see those priority values in pg_stat_replication. Isn't this confusing? If yes, it might be better to always assign 1 as the priority, for example.

Not a bug. Consensus against current design; no consensus on which replacement to adopt. Need to resolve that debate.