On Tue, Jan 24, 2012 at 10:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> 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.
>
> The former seems difficult because it's not easy to link libpqwalreceiver.so
> to the latch. I will consider about the latter.
Yes, it might be too hard, but lets look.
>>> 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.
>
> This means that apply_location might return the different location from
> pg_last_xlog_replay_location() on the standby, though in 9.1 they return
> the same. Which might confuse a user. No?
The two values only match on a quiet system anyway, since both are
moving forwards.
They will still match on a quiet system.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services