Fujii Masao wrote:
Attached is a patch for a synchronous log-shipping replication which
was discussed just a month ago. I would like you to review this patch
in Nov commit fest.
Here's some first quick comments:
AFAICS, there's no security, at all. Anyone that can log in, can become
a WAL sender, and receive all WAL for the whole cluster.
If the connection is jammed for a while, or just slow, is there
something that prevents the slave from falling so much behind that the
master checkpoints, archives, and deletes some WAL segments that are
still needed for the replication?
The outline of this patch is as follow;
1) Walsender
This is new process to focus on sending xlog through the position
which a backend requests on commit. Walsender calculates the area
of xlog to be replicated by a logic similar to XLogWrite.
At first, walsender is forked as a normal backend by postmater (i.e.
the standby connects to postmaster just like normal frontend).
A backend works as walsender after receiving "mimic-walsender"
message. Then, walsender is handled differently from a backend.
Now, the number of walsenders is restricted to one.
That feels kinda weird. I think it would be better if the client
indicated in the startup message that it wants to become WAL sender.
It'll be needed for the authentication.
And, there are some problems in this patch;
* This patch is somewhat big, though it should be subdivided for
review.
I've seen bigger :-). The signal handling changes might be a candidate
for splitting into a separate patch.
* Source code comments and documents are insufficient.
Sure. (though I've seen worse :-)).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
