On 28.03.2011 15:34, Simon Riggs wrote:
> On Mon, Mar 28, 2011 at 12:05 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> On 28.03.2011 13:14, Simon Riggs wrote:
>>>
>>> On Mon, Mar 28, 2011 at 10:52 AM, Simon Riggs<simon@2ndquadrant.com>
>>> wrote:
>>>>
>>>> You have no basis on which to prevent this.
>>>
>>> It's also already on the Open Items list, put there by you.
>>>
>>> Why is this even a discussion point?
>>
>> FWIW, I agree this is an additional feature that we shouldn't be messing
>> with at this point in the release cycle.
>
> There is an open item about what the UI is for sync commit/sync rep,
> which is the subject of this patch.
plus new functionality. For the UI part, you just need to change GUCs.
>> The 'apply' mode would be quite interesting, it would make it easier to
>> build load-balancing clusters. But the patch isn't up to the task on that
>> yet - the 'apply' status report is only sent after
>> wal_receiver_status_interval fills up, so you get long delays.
>
> Yes it's up to the task, you misread it. It will continue sending
> replies while apply<> flush and then it will fall back to the
> behaviour you mention.
There's nothing to wake up the walreceiver after applying a commit record.
Oh, you're relying on the periodic wakeups specified by
NAPTIME_PER_CYCLE (100ms). That's still on average a 50ms delay to every
commit. We should try to eliminate these polling loops, not make them
more important. In fact, we should raise NAPTIME_PER_CYCLE to, say,
1000ms, to reduce spurious wakeups on an idle system.
Am I reading the patch correctly that if the standby hasn't applied all
WAL yet, you send a reply message at every wakeup, whether or not any
progress has been made since last time? So if you have a
long-running-transaction in the standby, for example, conflicting with
WAL recovery, the standby will keep sending a status report to the
master every 100ms.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
