Skip site navigation (1) Skip section navigation (2)

Re: New replication mode: write

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New replication mode: write
Date: 2012-01-23 09:02:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Florian WeimerDate: 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 GrundmannDate: 2012-01-23 08:21:48
Subject: Re: Vacuum rate limit in KBps

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group