Fujii Masao wrote:
> On Tue, Nov 3, 2009 at 12:33 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira
>> <euler@timbira.com> wrote:
>>> BTW, are you going to submit another WIP patch for next commitfest?
>> Well, Heikki was going to keep working on this and Hot Standby between
>> CommitFests "until it gets committed", but things seem to be stalled
>> at the moment, possibly because Heikki is tied up with internal
>> EnterpriseDB projects. I don't think the hold-up is with Fujii Masao.
>
> BTW, my replication patch is on git repository:
>
> git://git.postgresql.org/git/users/fujii/postgres.git
> branch: replication
Thanks, I started to look at this again now. The consensus seems to be
to keep the current architecture where walreceiver is a child of postmaster.
I found the global LogstreamResult variable very confusing. It meant
different things in different processes. So I replaced it with static
globals in walsender.c and walreceiver.c, and renamed the fields to
match the purpose better. I removed some variables from shared memory
that are not necessary, at least not before we have synchronous mode:
Walsender only needs to publish how far it has sent, and walreceiver
only needs to tell startup process how far it has fsync'd.
I changed walreceiver so that it only lets the startup process to apply
WAL that it has fsync'd to disk, per recent discussion on hackers. Maybe
we want to support more esoteric modes in the future, but that's the
least surprising and most useful one.
Plus some other minor simplifications. My changes are in my git repo at
git://git.postgresql.org/git/users/heikki/postgres.git, branch
"replication".
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
