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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
