Re: New replication mode: write - Mailing list pgsql-hackers

On Mon, Jan 23, 2012 at 10:03 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

>>> 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.
>
> I'm afraid I could not understand your idea. Could you explain it in
> more detail?

We either tell libpqwalreceiver about the latch, or we tell
walreceiver about the socket used by libpqwalreceiver.

In either case we share a pointer from one module to another.

>>> 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.
>
> You mean to change the meaning of apply_location? Currently it indicates
> the end + 1 of the last replayed WAL record, regardless of whether it's
> a commit record or not. So too many replies can be sent per incoming
> message because it might contain many WAL records. But you mean to
> change apply_location only when a commit record is replayed?

There is no change to the meaning of apply_location. The only change
is that we send that message only when it has an updated value of
committed lsn.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services