On Thu, 25 Jul 2019 16:58:17 +0900
Michael Paquier wrote:
> On Wed, Jul 24, 2019 at 03:03:04PM +0200, Jehan-Guillaume de Rorthais wrote:
> > Unless I am missing something, another solution might be to use a dedicated
> > role to pg_receive{xlog|wal} with synchronous_commit lower than
> >
On Wed, Jul 24, 2019 at 03:03:04PM +0200, Jehan-Guillaume de Rorthais wrote:
> Unless I am missing something, another solution might be to use a dedicated
> role to pg_receive{xlog|wal} with synchronous_commit lower than
> remote_apply.
Aren't you confused by the same thing as I was upthread [1]?
Hi,
On Wed, 24 Jul 2019 11:29:28 +0900
Michael Paquier wrote:
> On Tue, Jul 23, 2019 at 08:00:41AM -0400, Jesper Pedersen wrote:
> > Sure.
>
> Thanks. Applied down to 9.6 where remote_apply has been introduced,
> with tweaks for 9.6 as the tool is named pg_receivexlog there.
Sorry to step
Hi,
On 7/23/19 10:29 PM, Michael Paquier wrote:
Thanks. Applied down to 9.6 where remote_apply has been introduced,
with tweaks for 9.6 as the tool is named pg_receivexlog there.
Thanks to everybody involved !
Best regards,
Jesper
On Tue, Jul 23, 2019 at 08:00:41AM -0400, Jesper Pedersen wrote:
> Sure.
Thanks. Applied down to 9.6 where remote_apply has been introduced,
with tweaks for 9.6 as the tool is named pg_receivexlog there.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 7/22/19 8:08 PM, Michael Paquier wrote:
+to something other than
Looks fine to me. Just a tiny nit. For the second reference to
synchronous_commit, I would change the link to a markup.
Sure.
Best regards,
Jesper
>From f6c5e9128e0779f928d94bf9bcc8813bf03150f0 Mon Sep 17
On Mon, Jul 22, 2019 at 01:25:41PM -0400, Jesper Pedersen wrote:
> Hi,
>
> On 7/21/19 9:48 PM, Michael Paquier wrote:
> > > Since pg_receivewal does not apply WAL, you should not allow it to
> > > become a synchronous standby when synchronous_commit = remote_apply.
> > > If it does, it will
Hi,
On 7/21/19 9:48 PM, Michael Paquier wrote:
Since pg_receivewal does not apply WAL, you should not allow it to
become a synchronous standby when synchronous_commit = remote_apply.
If it does, it will appear to be a standby which never catches up,
which may cause commits to block. To avoid
On Fri, Jul 19, 2019 at 02:04:03PM -0400, Robert Haas wrote:
> You could just say something like:
>
> Since pg_receivewal does not apply WAL, you should not allow it to
> become a synchronous standby when synchronous_commit = remote_apply.
> If it does, it will appear to be a standby which never
On Tue, Jul 16, 2019 at 9:38 PM Michael Paquier wrote:
> I think we should really document the caveat with priority-based sets
> of standbys as much as quorum-based sets. For example if a user sets
> synchronous_commit = remote_apply in postgresql.conf, and then sets
> s_s_names to
Hi,
On 7/18/19 9:09 PM, Michael Paquier wrote:
pg_receivewal -D /tmp/wal -S replica1 --synchronous -h localhost -p 5432 -U
repluser -W
psql -c 'SELECT * FROM pg_stat_replication;' postgres
psql -c 'SELECT * FROM pg_replication_slots;' postgres
psql -c 'CREATE DATABASE test' postgres
In what
Hi,
On 7/18/19 9:27 PM, Michael Paquier wrote:
The location of the warning is
also harder to catch for the reader, so instead let's move it to the
top where we have an extra description for --synchronous. I am
finishing with the attached that I would be fine to commit and
back-patch as needed.
On Fri, 2019-07-19 at 10:27 +0900, Michael Paquier wrote:
> On Thu, Jul 18, 2019 at 08:40:36AM -0400, Jesper Pedersen wrote:
> > On 7/18/19 1:29 AM, Michael Paquier wrote:
> > > Or more simply like that?
> > > "Note that while WAL will be flushed with this setting,
> > > pg_receivewal never
On Thu, Jul 18, 2019 at 08:40:36AM -0400, Jesper Pedersen wrote:
> On 7/18/19 1:29 AM, Michael Paquier wrote:
>> Or more simply like that?
>> "Note that while WAL will be flushed with this setting,
>> pg_receivewal never applies it, so synchronous_commit must not be set
>> to remote_apply if
On Thu, Jul 18, 2019 at 08:39:48AM -0400, Jesper Pedersen wrote:
> mkdir /tmp/wal
> initdb /tmp/pgsql
> pg_ctl -D /tmp/pgsql -l /tmp/logfile start
> psql postgres
> SELECT pg_create_physical_replication_slot('replica1');
> CREATE ROLE repluser WITH LOGIN REPLICATION PASSWORD 'replpass';
> \q
>
>
Hi,
On 7/18/19 1:29 AM, Michael Paquier wrote:
Or more simply like that?
"Note that while WAL will be flushed with this setting,
pg_receivewal never applies it, so synchronous_commit must not be set
to remote_apply if pg_receivewal is a synchronous standby, be it a
member of a priority-based
Hi Laurenz,
On 7/17/19 5:21 PM, Laurenz Albe wrote:
That's factually wrong. "on" (wait for WAL flush) works fine with
pg_receivewal, only "remote_apply" doesn't.
Please, try
mkdir /tmp/wal
initdb /tmp/pgsql
pg_ctl -D /tmp/pgsql -l /tmp/logfile start
psql postgres
SELECT
On Wed, Jul 17, 2019 at 11:21:06PM +0200, Laurenz Albe wrote:
> Ok, here's another attempt:
>
>Note that while WAL will be flushed with this setting,
>pg_receivewal never applies it, so
> must not be set to
>remote_apply if pg_receivewal
>is the only synchronous standby.
>
On Wed, 2019-07-17 at 13:59 -0400, Jesper Pedersen wrote:
> +
> +Note that while WAL will be flushed with this setting,
> +pg_receivewal never applies it, so
> + must not be set to
> +remote_apply or on
> +if pg_receivewal is the only synchronous
>
Hi,
On 7/17/19 4:04 AM, Michael Paquier wrote:
How about adding "or priority-based" after "quorum-based"?
I would be fine with that for the first part. I am not sure of what a
good formulation would be for the second part of the sentence. Now it
only refers to quorum, but with priority sets
On Wed, Jul 17, 2019 at 07:40:48AM +0200, Laurenz Albe wrote:
> I understand the concern, I'm just worried that too much accuracy may
> render the sentence hard to read.
>
> How about adding "or priority-based" after "quorum-based"?
I would be fine with that for the first part. I am not sure of
On Wed, 2019-07-17 at 10:38 +0900, Michael Paquier wrote:
> +
> +Note that while WAL will be flushed with this setting,
> +pg_receivewal never applies it, so
> + must not be set to
> +remote_apply if
> pg_receivewal
> +is the only synchronous
On Tue, Jul 16, 2019 at 01:03:12PM -0400, Jesper Pedersen wrote:
> Here is the patch for that.
+
+Note that while WAL will be flushed with this setting,
+pg_receivewal never applies it, so
+ must not be set to
+remote_apply if
pg_receivewal
+is the
Hi,
On 7/16/19 12:28 PM, Laurenz Albe wrote:
This is not true in all cases as since 9.6 it is possible to specify
multiple synchronous standbys. So if for example pg_receivewal and
another synchronous standby are set in s_s_names and that the number
of a FIRST (priority-based) or ANY (quorum
On Tue, 2019-07-16 at 14:05 +0900, Michael Paquier wrote:
> >> How about
> >> Note that while WAL will be flushed with this setting,
> >> pg_receivewal never applies it, so
> >> must not be set to
> >> remote_apply if
> >> pg_receivewal
> >> is the
On Wed, Jul 10, 2019 at 11:26:04AM -0400, Jesper Pedersen wrote:
> On 7/10/19 10:24 AM, Alvaro Herrera wrote:
> > +1 to document this caveat.
>>
>> How about
>> Note that while WAL will be flushed with this setting,
>> pg_receivewal never applies it, so
>> must not be
On Wed, Jul 10, 2019 at 09:12:46PM +0200, Laurenz Albe wrote:
> 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
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
Hi,
On 7/10/19 10:24 AM, Alvaro Herrera wrote:
+1 to document this caveat.
How about
Note that while WAL will be flushed with this setting,
pg_receivewal never applies it, so
must not be set to
remote_apply if
pg_receivewal
is the only synchronous
On 2019-Jul-09, Jesper Pedersen wrote:
> +
> +Note that while WAL will be flushed with this setting,
> +it will never be applied, so linkend="guc-synchronous-commit"/> must
> +not be set to remote_apply if
> pg_receivewal
> +is the only synchronous
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
Hi,
On 7/9/19 6:22 PM, Laurenz Albe wrote:
Works for me.
Marked as "ready for committer".
Thank you !
Best regards,
Jesper
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
Jesper Pedersen wrote:
> Thanks for the review, and the changes.
>
> However, I think it belongs in the --synchronous section, so what about
> moving it there as attached ?
Works for me.
Marked as "ready for committer".
Yours,
Laurenz Albe
Hi Laurenz,
On 7/9/19 5:16 AM, Laurenz Albe wrote:
On Thu, 2019-06-27 at 10:06 -0400, Jesper Pedersen wrote:
Here is a patch for the pg_receivewal documentation to highlight that
WAL isn't acknowledged to be applied.
I think it is a good idea to document this, but I have a few quibbles
with
On Thu, 2019-06-27 at 10:06 -0400, Jesper Pedersen wrote:
> Here is a patch for the pg_receivewal documentation to highlight that
> WAL isn't acknowledged to be applied.
I think it is a good idea to document this, but I have a few quibbles
with the patch as it is:
- I think there shouldn't be
36 matches
Mail list logo
