From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New replication mode: write |
Date: | 2012-01-24 11:00:27 |
Message-ID: | CA+U5nMJWXpnUPU61KEiTMN049nAiw0W_8wXkDTfnYXS73hBhnw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 24, 2012 at 10:47 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-01-24 11:22:16 | Re: Online base backup from the hot-standby |
Previous Message | Simon Riggs | 2012-01-24 10:54:56 | Re: Online base backup from the hot-standby |