On Wed, 2008-11-05 at 23:17 +0900, Fujii Masao wrote:
> Authentication
> -----------------------
> As pointed out at another thread, for authentication, I defined the database
> only for replication (named "walsender" tentatively). walsender database is
> not pseudo but created by initdb like postgres database, because the user
> can re-create it easily even if it is lost accidentally.
>
> If the startup packet specifies walsender database, a backend declares
> postmaster working as walsender. Then, the backend is removed from
> BackendList and managed as background process by postmaster.
>
> Replication message
> ---------------------------------
> I defined new message type 'R', which means the start of replication. If the
> message is received, walsender will perform the main routine. Of course,
> a backend who is not walsender cannot perform the routine.
I don't understand why you've done it this way. Can you explain? This
stuff about a walsender database sounds like it has a purpose, but I'm
not sure what it is.
The route I would have taken would be to add walsender and walreceiver
as new auxiliary processes. They would start via AuxiliaryProcessMain()
in bootstrap/bootstrap.c. ISTM this would be slightly less code as well
and not too much change from what you have now. After a quick look, most
of the rest of the patch looks correct.
I would hope that walsender and walreceiver would start like that.
walsender would start at same time as walwriter. walreceiver can start
earlier, for later discussion.
> Shutdown
> ----------------
> I arranged the shutdown timing of walsender. For example, in smart
> shutdown case, walsender should exit after bgwriter at least in order to
> replicate a shutdown checkpoint xlog.
Agreed.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support