On Mon, Jan 23, 2012 at 4:58 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Mon, Jan 16, 2012 at 12:45 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>> Please add the Apply mode.
>>> OK, will do.
>> Done. Attached is the updated version of the patch.
> I notice that the Apply mode isn't fully implemented. I had in mind
> that you would add the latch required to respond more quickly when
> only the Apply pointer has changed.
> Is there a reason not to use WaitLatchOrSocket() in WALReceiver? Or
> was there another reason for not implementing that?
I agree that the feature you pointed is useful for the Apply mode. But
I'm afraid that implementing that feature is not easy and would make
the patch big and complicated, so I didn't implement the Apply mode first.
To make the walreceiver call WaitLatchOrSocket(), we would need to
merge it and libpq_select() into one function. But the former is the backend
function and the latter is the frontend one. Now I have no good idea to
merge them cleanly.
If we send back the reply as soon as the Apply pointer is changed, I'm
afraid quite lots of reply messages are sent frequently, which might
cause performance problem. This is also one of the reasons why I didn't
implement the quick-response feature. To address this problem, we might
need to change the master so that it sends the Wait pointer to the standby,
and change the standby so that it replies whenever the Apply pointer
catches up with the Wait one. This can reduce the number of useless
reply from the standby about the Apply pointer.
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
In response to
pgsql-hackers by date
|Next:||From: Florian Weimer||Date: 2012-01-23 09:03:04|
|Subject: Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility|
|Previous:||From: Benedikt Grundmann||Date: 2012-01-23 08:21:48|
|Subject: Re: Vacuum rate limit in KBps|