Hi,
On 7/10/19 4:04 AM, Michael Paquier wrote:
> On Wed, Jul 10, 2019 at 12:22:02AM +0200, Laurenz Albe wrote:
>> Works for me.
>>
>> Marked as "ready for committer".
>
> Hmm. synchronous_commit is user-settable, which means that it is
> possible to enforce a value in the connection string doing the
> connection. Isn't that something we had better enforce directly in
> the tool? In this case what could be fixed is GetConnection() which
> builds the connection string parameters. One thing that we would need
> to be careful about is that if the caller has provided a parameter for
> "options" (which is plausible as wal_sender_timeout is user-settable
> as of 12), then we need to make sure that the original value is
> preserved, and that the enforced of synchronous_commit is appended.
>
I think that the above is out-of-scope for this patch. And ...
> Or, as you say, we just adjust the documentation. However I would
> recommend adding at least an example of connection string which uses
> "options" if the server sets synchronous_commit to "remote_apply" in
> this case. Still it seems to me that we have ways to reduce the
> confusion automatically.
The patch tries to highlight that if you f.ex. have
postgresql.conf
===============
synchronous_commit = remote_apply
synchronous_standby_names = '*'
and you _only_ have pg_receivewal connected then changes are only
applied locally to the primary instance and any client (psql, ...) won't
get acknowledged. The replay_lsn for the pg_receivewal connection will
keep increasing, so
env PGOPTIONS="-c synchronous_commit=remote_write" pg_receivewal -D
/tmp/wal -S replica1 --synchronous
won't help you.
We could add some wording around 'synchronous_standby_names' if it makes
the case clearer.
Best regards,
Jesper
