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.
> 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.
> PS. you're missing some break's in the switch-statement in
> SyncRepWaitForLSN(), effectively making the patch do nothing.
OK, thanks.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services