Re: pg_receivewal documentation

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