On Mon, Jan 23, 2012 at 9:02 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Mon, Jan 23, 2012 at 4:58 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> On Mon, Jan 16, 2012 at 12:45 PM, Fujii Masao <masao.fu...@gmail.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.
We can wait on the socket wherever it comes from. poll/select doesn't care how we got the socket. So we just need a common handler that calls either walreceiver/libpqwalreceiver function as required to handle the wakeup. > 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. We send back one reply per incoming message. The incoming messages don't know request state and checking that has a cost which I don't think is an appropriate payment since we only need this info when the link goes quiet. When the link goes quiet we still need to send replies if we have apply mode, but we only need to send apply messages if the lsn has changed because of a commit. That will considerably reduce the messages sent so I don't see a problem. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
