Re: pg_receivewal documentation

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: jesper(dot)pedersen(at)redhat(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_receivewal documentation
Date: 2019-07-10 19:12:46
Message-ID: 0eba4de66211262e9014300ee78f33b382a58603.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2019-07-10 at 17:04 +0900, Michael Paquier wrote:
> 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.

I don't follow.

Are you talking about the replication connection from pg_receivewal
to the PostgreSQL server? That wouldn't do anything, because it is
the setting of "synchronous_commit" for an independent client
connection that is the problem:

- pg_receivewal starts a replication connection.

- It is added to "synchronous_standby_names" on the server.

- A client connects. It sets "synchronous_commit" to "remote_apply".

- If the client modifies data, COMMIT will hang indefinitely,
because pg_receivewal will never send confirmation that it has
applied the changes.

One alternative option I see is for pg_receivewal to confirm that
it has applied the changes as soon as it flushed them.
It would be cheating somewhat, but it would work around the problem
in a way that few people would find surprising.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2019-07-10 19:44:14 Re: Add parallelism and glibc dependent only options to reindexdb
Previous Message Robert Haas 2019-07-10 19:08:33 Re: POC: Cleaning up orphaned files using undo logs