On Tue, Jul 16, 2019 at 9:38 PM Michael Paquier <mich...@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
