On Tue, Nov 11, 2008 at 9:12 AM, Simon Riggs <simon@2ndquadrant.com> 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
