Re: pg_receivewal documentation

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: pg_receivewal documentation
Дата
Msg-id 0eba4de66211262e9014300ee78f33b382a58603.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: pg_receivewal documentation  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pg_receivewal documentation  (Michael Paquier <michael@paquier.xyz>)
Список 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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: POC: Cleaning up orphaned files using undo logs
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Add parallelism and glibc dependent only options to reindexdb