From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Streaming replication and non-blocking I/O |
Date: | 2009-12-17 13:00:55 |
Message-ID: | 3f0b79eb0912170500y24b5a1ag4f9440459b2b5bf7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 17, 2009 at 9:02 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-12-17 13:05:13 | Re: Hot Standby and prepared transactions |
Previous Message | Heikki Linnakangas | 2009-12-17 12:02:29 | Re: Streaming replication and non-blocking I/O |