On Mon, 2008-11-10 at 18:22 +0900, Fujii Masao wrote:
> Yeah, I also add walsender as new auxiliary process at first. But,
> during coding,
> I made out that this is more complicated for code and user.
>
> First problem : Which process accepts the connection from standby?
> IMO, *postmaster* should accept it like normal database access. Since
> we
> can use the existing connection establishment logic, the change of the
> code
> is smaller and it's easier to use. So, I added walsender as a special
> backend
> which is forked when standby connects to postmaster. Is there any
> advantage
> which walsender or other processes accept the connection from standby?
> Second problem : What should walsender do after the termination of the
> connection from standby? should die?, or remain alive and wait for
> next
> connection? IMO, we should handle it like normal database access, i.e.
> exit walsender. This and adding walsender as an auxiliary process
> seldom
> meet, I think.
>
> Does that answer you? Am I missing something?
It's good to see your reasons written down.
OK, I think I could like this way around. The "walsender" database
allows us to enforce restrictions in pg_hba.conf. Also avoids needing to
run a long running transaction to initiate wal sending feature, if we do
it just with user function. I'd like to see a longer README explaining
these design aspects though.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support