On Tue, Nov 11, 2008 at 9:12 AM, Simon Riggs <[EMAIL PROTECTED]> wrote: > > 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.
OK, thanks. I'll try to write them. -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
