On Tue, Jan 24, 2012 at 10:47 AM, Fujii Masao <masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
