On Tue, Jul 16, 2019 at 9:38 PM Michael Paquier <michael@paquier.xyz> wrote:
> I think we should really document the caveat with priority-based sets
> of standbys as much as quorum-based sets. For example if a user sets
> synchronous_commit = remote_apply in postgresql.conf, and then sets
> s_s_names to '2(pg_receivewal, my_connected_standby)' to get a
> priority-based set, then you have the same problem, and pg_receivewal
> is not the only synchronous standby in this configuration. The patch
> does not cover that case properly.
I don't agree with this approach. It seems to me that the original was
too precise already, and making it more precise only exacerbates the
situation. The point is that synchronous_commit = remote_apply is
*categorically* a bad idea for sessions running pg_receivewal. The
reason why you're adding all this complexity is to try to distinguish
between the case where it's merely a bad idea and the case where it
will also completely fail to work. But why is it important to describe
the scenarios under which it will altogether fail to work?
You could just say something like:
Since pg_receivewal does not apply WAL, you should not allow it to
become a synchronous standby when synchronous_commit = remote_apply.
If it does, it will appear to be a standby which never catches up,
which may cause commits to block. To avoid this, you should either
configure an appropriate value for synchronous_standby_names, or
specify an application_name for pg_receivewal that does not match it,
or change the value of synchronous_commit to something other than
remote_apply.
I think that'd be a lot more useful than enumerating the total-failure
scenarios.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company