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
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 |