Re: Streaming replication and non-blocking I/O - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Streaming replication and non-blocking I/O
Date
Msg-id 3f0b79eb0912170500y24b5a1ag4f9440459b2b5bf7@mail.gmail.com
Whole thread Raw
In response to Re: Streaming replication and non-blocking I/O  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Streaming replication and non-blocking I/O  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Thu, Dec 17, 2009 at 9:02 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
>> And, I think that such backend should switch to walsender mode when the startup
>> packet arrives. Otherwise, we would have to authenticate such backend twice
>> on different context, i.e., a normal backend and walsender. So the settings for
>> each context would be required in pg_hba.conf. This is odd, I think. Thought?
>
> True.

Currently this switch depends on whether XLOG_STREAMING_CODE is sent from the
standby or not, also which depends on whether PQstartXLogStreaming() is called
or not. But, as the next step, we should get rid of also such changes of libpq.

I'm thinking of making the standby send the "walsender-switch-code" the same way
as application_name; walreceiver always specifies the option like
"replication=on"
in conninfo string and calls PQconnectdb(), which sends the code as a part of
startup packet. And, the environment variable for that should not be defined to
avoid user's mis-configuration, I think.

Thought? Better idea?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Streaming replication and non-blocking I/O
Next
From: Simon Riggs
Date:
Subject: Re: Hot Standby and prepared transactions