From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Bernd Helmle <mailings(at)oopsware(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: recovery_min_apply-delay and remote_apply |
Date: | 2016-09-19 17:44:08 |
Message-ID: | CA+Tgmob+wQ9V=rXPy8s3fbTfachB6WE3D++CCbRvqxpHRoaL-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 16, 2016 at 5:55 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Sat, Sep 17, 2016 at 8:45 AM, Bernd Helmle <mailings(at)oopsware(dot)de> wrote:
>> Current PostgreSQL Documentation on recovery.conf has this about
>> recovery_min_apply_delay[1]:
>>
>> ---<---
>>
>> This parameter is intended for use with streaming replication deployments;
>> however, if the parameter is specified it will be honored in all cases.
>> Synchronous replication is not affected by this setting because there is
>> not yet any setting to request synchronous apply of transaction commits.
>>
>> --->---
>>
>> If i understand correctly, this is not true anymore with 9.6, where
>> remote_apply will have exactly the behavior the paragraph above wants to
>> contradict: any transaction executed with synchronous_commit=remote_apply
>> will wait at least recovery_min_apply_delay to finish. Given that
>> synchronous_commit can be controlled by any user, this might be dangerous
>> if someone doesn't take care enough.
>
> Yes, I missed that sentence. Thanks.
>
>> I think we need a doc patch for that at least, see attached patch against
>> master, but 9.6 should have a corrected one, too.
>
> +1
Committed with a bit of adjustment, and back-patched to 9.6.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-09-19 18:09:00 | Re: Parallel sec scan in plpgsql |
Previous Message | Robert Haas | 2016-09-19 17:22:56 | Re: more parallel query documentation |