On Wed, Nov 5, 2008 at 12:51 AM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> Fujii Masao wrote:
>>
>> On Fri, Oct 31, 2008 at 11:12 PM, Heikki Linnakangas
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> 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.
>>
>> One simple solution is to define the database only for replication. In
>> this solution,
>> we can handle the authentication for replication like the usual database
>> access.
>> That is, pg_hba.conf, the cooperation with a database role, etc are
>> supported also
>> in replication. So, a user can set up the authentication rules easily.
>
> You mean like a pseudo database name in pg_hba.conf, and in the startup
> message, that actually means "connect for replication"? Yeah, something like
> that sounds reasonable to me.
Yes, I would define a pseudo database name for replication.
A backend works as walsender only if it received the startup packet
including the
database name for replication. But, authentication and initialization
continue till
ReadyForQuery is sent. So, I assume that walsender starts replication
after sending
ReadyForQuery and receiving a message for replication. In this design, some
features (e.g. post_auth_delay) are supported as they are. Another advantage is
that a client can use lipq, such as PQconnectdb, for the connection
for replication
as they are.
Between ReadyForQuery and a message for replication, a client can
issue some queries.
At least, my walreceiver would query timeline ID and request
xlog-switch (In my previous
patch, they are exchanged after walsender starts, but it has little
flexibility). Of course,
I have to create new function which returns current timeline ID.
Initial sequence of walsender
----------------
1) process the startup packet
1-1) if the database name for replication is specified, a backend
would declare postmaster
that I am walsender (remove its backend from BackendList, etc).
2) authentication and initialization (BackendRun, PostgresMain)
3) walsender sends ReadyForQuery
4) a client queries timeline ID and requests xlog-switch
6) a client requests the start of WAL streaming
6-1) if a backend is not walsender, it refuses the request.
I correct the code and post it ASAP.
Regards,
--
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
