From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: Walsender process patch v1 for Synch Rep |
Date: | 2008-11-07 08:49:40 |
Message-ID: | 1226047780.27904.47.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2008-11-07 08:51:13 | Re: Patch for ALTER DATABASE WITH TABLESPACE |
Previous Message | Matteo Beccati | 2008-11-07 08:21:03 | Re: regression in analyze |